bajos fields
Burkhart Holznagel
wie ihr bemerkt habt, habe ich die fieldverwaltung umgeschrieben.
jetzt wird echt nur soviel speicher verbraucht wie notwendig.
so wie ich das alles verstanden haben unterscheidet die jvm zwischen
final primitive daten und strings -> wird kein speicherplatz auf dem
heap bereitgestellt->der compiler setzt die werte direkt ein
final objekte -> brauchen speicherplatz
non final static fields -> brauchen speicherplatz im "class objekt"
und werden in classfile.c anfangs erzeugt
non final "normale" fields -> brauchen speicherplatz im heap und
werden mit dem NEW-bytecode erzeugt
ich habe schon einige tests gemacht, ob das alles wirklich so ist und
vielleicht doch noch irgendwie
ein haken dabei ist. wenn ihr was eigenartiges bemerkt schreibt mir
das, das liegt bestimmt
an einem fehler in meinem code.
grüße von burkhart
Christopher Hrabia
ich bin zurück aus dem Urlaub und freue mich das hier gleich lesen zu
können! Klingt super! Werde ich gleich mal ausprobieren!
Viele Grüße
Christopher
Am 14. September 2011 16:18 schrieb Burkhart Holznagel
<burkhart....@googlemail.com>:
--
Mit freundlichen Grüßen
Christopher Hrabia
(c.hr...@gmail.com)
Christopher Hrabia
kann es sein das du vergessen hast thread.c einzuchecken?
JAVALANGNATIVE/thread.c: In function 'nativeSetPriority':
JAVALANGNATIVE/thread.c:64: error: 'fNO' undeclared (first use in this function)
JAVALANGNATIVE/thread.c:64: error: (Each undeclared identifier is
reported only once
JAVALANGNATIVE/thread.c:64: error: for each function it appears in.)
make: *** [JAVALANGNATIVE/thread.o] Fehler 1
Viele Grüße
Christopher Hrabia
sag mal übersehe ich hier wieder etwas?
final primitive daten und strings -> wird kein speicherplatz auf dem
>>> heap bereitgestellt
Aber im class objekt verbrauchen wir doch trotzdem Speicherplatz? Oder
bedeutet das jetzt doch, dass ich meine vielen Konstanten verwenden
kann? Ich habs nämlich ausprobiert und habe einfach nur dann einen
Fehler beim allokieren bekommen.