To kedy sa dealokovalo f, zaviselo od velkosti pola, cize ci sa este
pred cyklom automaticky spustilo gc.
Treba si vsak uvedomit ze kompilator nemoze takmer vobec ovplyvnit
dealokaciu - ak by bol predposledny prikaz bloku volanie nejakej metody,
tak uz nik nevie co sa stalo. Nejako vsak ten gc vie ze na f uz nic
neukazuje, alebo je v inej generacii ako stuff. Napada mi reference
counting, ale to sa zevraj nepouziva v gc-ckach (viem ale ze ref-count.
napr. pouziva Cocoa).
Zdenek Tronicek wrote / napísal(a):
Ja jsem popisoval, jak se chova JVM za "normalnich" podminek. V
okamziku, kdy zacne dochazet pamet, zacne JVM drsne optimalizovat. A
ze to umi, lze videt na tomto prikladu (z Vaseho kodu jsem vypustil
blok):
System.out.println("start");
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim pole Stuff
Stuff[] theStuffs = new Stuff[100000];
for (int i = 0; i < theStuffs.length; i++) {
theStuffs[i] = new Stuff();
}
// nez se dojde sem, je po objektu f
while (true) {
System.out.println("aaa");
Runtime.getRuntime().gc();
try {
Thread.sleep(200);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Na mem pocitaci dojde k dealokaci objektu f jeste drive, nez se
vstoupi do smycky while. Jak k tomu muze dojit? Java neco takoveho
neumoznuje, jde ciste o optimalizaci JVM.
Mimochodem, myslim, ze tohle je na hranici toho, co jeste lze delat,
protoze kdyby nejaky program spolehal na to, ze objekt nemuze byt
dealokovan pred koncem platnosti promenne f (tj. pred koncem metody),
nebude fungovat.
Pokud jde o ty lokalni promenne, tak ve vypise javap je jejich pocet
za retezcem Locals= a po dobu vykonavani metody se tato hodnota nemeni.
Z.T.
