Re: Cteni caroveho kodu v Jave
Zdravim, zrovna nedavno jsem toto resil, report od uzivatele znel Thinkpad ma spatnej USB, nefunguje na nem scanner caroveho kodu kterej jinde funguje Problem - na notebooku byla vypnuta numericka klavesnice, a on na ni zkousel vytukat ten kod (t.j. 4 = - , 7 = home). Zapnuti numericke pomohlo, ale pak se na klavesnici nedalo psat pismenka. Nakonec jsem nasel na webu jak se dany scanner konfiguruje, tento se konfiguroval pres specialni carove kody v dokumentu ktery bylo potrea vytisknout. V praci mame jiny, ten se konfiguruje SW cestou. Ohledne vytukavani byly 3 moznosti: numericka klavesnice (problem s notebookem), ciselna rada nad klavesami (problem s cestinou) a vytukavani ascii kodu pres ALT+kod (= reseni) S pozdravem Jindra Petr Burdik wrote: Ahoj, na notebooku byvava problem v tom, ze tam neni takova ta numericka cast. Kdysi jsem se na tom malem vypekl. Protoze jsem si prepinal tu ctecku do rezimu numericke klavesnice a porad to nefungovalo. Numericka cast chybela. Pet Dne Fri, 20 Feb 2009 12:44:45 +0100 Petr Pokorný toneofwi...@gmail.com napsal/-a: Zdravim konferenci, Zkousim si cteni caroveho kodu na klavesnicove ctece a System.in skutecne vraci kod. Ale mam problem na notebooku pres usb redukci, to mi nefunguje. Mete nekdo nejakou radu nebo jsou na redukce to ctecky nachylne. Diky Petr From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Pavel Marek Sent: Tuesday, January 20, 2009 7:21 AM To: Java Subject: Re: Cteni caroveho kodu v Jave Není na tom nic záhadnýho. Před pár lety jsem dělal program s čtečkou čárových kódů. Čtečka se spojila kabely s klávesnicí a fungovala přesně jako klávesnice. Takže v programu jsi byl v okýnku ID zboží, sejmul jsi kód, ten se v té položce objevil a ještě se to samo odentrovalo. Prostě rozdíl mezi sejmutím čárového kódu a napsáním toho ID na klávesnici nebyl žádný. Není tedy třeba žádná speciální knihovna. Pavel Marek. __ Informace od ESET Smart Security, verze databaze 3774 (20090117) __ Tuto zpravu proveril ESET Smart Security. http://www.eset.cz -- Jindrich Vimr E-mail: jv...@softeu.com Cell: +420 775 638 011, Phone: +420 371 124 386 SoftEU s.r.o. Lochotínská 18, 301 00 Plzeň, Czech Republic Phone +420 371 124 300,Fax: +420 373 729 301
Kedy dojde k odstraneniu objektu?
Ahoj.
Kedze som v jave novy a prechadzam do nej z C++, obcas sa pri programovani
pozastavim nad nejakou vecou, o ktorej viem, ze tak nejak funguje, ale aby
som mal pokojne spanie, musim si to osahat vlastnymi rukami.
Prave som napisal nejaku class-u, ktora obaluje urcite podclassy a poskutyje
urcitu ucelenu funkcionalitu. Tie jej podclassy rozne ukazuju sami do seba,
medzi sebou a tak podobne, proste o sebe vedia. A tak sa mi hlavou zacali
tocit otazky okolo garbage collectoru, platnosti objektov, case ich uvolnenia
z pamati a tak podobne.
A kedze som bol byvalym kolegom ( zdravim Ta Nhac :) ) presviedsany, ze reci
okolo javy a jej pamatovej nenazranosti su nezmysly, vyrobil som si rovno
maly test:
// obycajna class-a. Vypisom testujem cas jej odstranenia z pamati
// urdzuje odkaz na svoju nadradenu classu, pretoze obe budem nejak
// zapuzdrovat do jedneho celku a vyuzivaju medzi sebou svoje sluzby
public class Foo {
private Stuff stuff;
public Foo ( Stuff s ) {
this.stuff = s;
}
@Override
protected void finalize() {
System.out.println(finalize Foo);
}
}
// nejaka dalsia classa
public class Stuff {
public Foo foo = new Foo ( this );
@Override
protected void finalize() {
System.out.println(finalize Stuff);
}
}
public static void main(String[] args) {
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim Stuff, ten si vytvori dalsie Foo
Stuff s = new Stuff();
// f = null
}
// tu uz neexistuje ani Foo f, ani Stuff f, mozu byt zmazane
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
Thread.sleep(2000);
}
}
}
Kupodivu, vystupom programu bol nasledovny vypis:
start
aaa
aaa
aaa
...
Po pol hodine som to nechapajuc breakol.
Odkomentoval som to f = null
Vystup:
start
aaa
finalize Foo
aaa
aaa
aaa
...
Toto som nechal bezat par minut. Garbage collector ten Stuff nie a nie zmazat.
Priznam sa, ze to uplne nechapem, pretoze za prvou zlozenou zatvorkou }
straca Stuff s platnost a nema dovod viac existovat v pamati.
Mna by zaujimalo, kedy ho gc uvolni, pretoze pokial bude mat Stuff 2GB, bude
aplikacia bezdovodne kradnut systemu 2GB pamati na bordel, ktory uz nikdy
nepouzije, boh vie na aku dlhu dobu.
Diky.
--
Dusan
Re: Kedy dojde k odstraneniu objektu?
Garbage collector funguje nedeterministicky a v zavislosti od
implementacie.
Inak povedane,
* neda sa zarucit jeho spustenie
* System.gc() je len navrh, ze ma zbehnut.
Letmy pohlad do dokumentacie podla mna nikde nehovori, ze premenna,
ktora vypadla zo scope MUSI byt zgarbagecollectovana.
Pokial mojmu zraku neusiel memory leak, tak by som jednoducho povedal,
ze GC usudil, ze kvoli dvom smiesnym instanciam nema zmysel
spustat GC masineriu.
RN
On Tue, 24 Feb 2009 17:04:45 +0100, Dusan Zatkovsky msk.c...@gmail.com
wrote:
Ahoj.
Kedze som v jave novy a prechadzam do nej z C++, obcas sa pri
programovani
pozastavim nad nejakou vecou, o ktorej viem, ze tak nejak funguje, ale
aby
som mal pokojne spanie, musim si to osahat vlastnymi rukami.
Prave som napisal nejaku class-u, ktora obaluje urcite podclassy a
poskutyje
urcitu ucelenu funkcionalitu. Tie jej podclassy rozne ukazuju sami do
seba,
medzi sebou a tak podobne, proste o sebe vedia. A tak sa mi hlavou zacali
tocit otazky okolo garbage collectoru, platnosti objektov, case ich
uvolnenia
z pamati a tak podobne.
A kedze som bol byvalym kolegom ( zdravim Ta Nhac :) ) presviedsany, ze
reci
okolo javy a jej pamatovej nenazranosti su nezmysly, vyrobil som si rovno
maly test:
// obycajna class-a. Vypisom testujem cas jej odstranenia z pamati
// urdzuje odkaz na svoju nadradenu classu, pretoze obe budem nejak
// zapuzdrovat do jedneho celku a vyuzivaju medzi sebou svoje sluzby
public class Foo {
private Stuff stuff;
public Foo ( Stuff s ) {
this.stuff = s;
}
@Override
protected void finalize() {
System.out.println(finalize Foo);
}
}
// nejaka dalsia classa
public class Stuff {
public Foo foo = new Foo ( this );
@Override
protected void finalize() {
System.out.println(finalize Stuff);
}
}
public static void main(String[] args) {
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim Stuff, ten si vytvori dalsie Foo
Stuff s = new Stuff();
// f = null
}
// tu uz neexistuje ani Foo f, ani Stuff f, mozu byt zmazane
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
Thread.sleep(2000);
}
}
}
Kupodivu, vystupom programu bol nasledovny vypis:
start
aaa
aaa
aaa
...
Po pol hodine som to nechapajuc breakol.
Odkomentoval som to f = null
Vystup:
start
aaa
finalize Foo
aaa
aaa
aaa
...
Toto som nechal bezat par minut. Garbage collector ten Stuff nie a nie
zmazat.
Priznam sa, ze to uplne nechapem, pretoze za prvou zlozenou zatvorkou }
straca Stuff s platnost a nema dovod viac existovat v pamati.
Mna by zaujimalo, kedy ho gc uvolni, pretoze pokial bude mat Stuff 2GB,
bude
aplikacia bezdovodne kradnut systemu 2GB pamati na bordel, ktory uz nikdy
nepouzije, boh vie na aku dlhu dobu.
Diky.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Kedy dojde k odstraneniu objektu?
Dobry den,
myslim, ze pokud chcete porozumet tomu, proc nebyl objekt foo
odstranen z pameti, je nutne se trochu podivat na bytecode. V Jave
funguje alokace lokalnich promennych tak, ze pri VSTUPU DO METODY se
na zasobniku naalokuje prostor dostatecne velky na to, aby se tam
vesly vsechny promenne deklarovane v teto metode. Tento prostor se
deli na tzv. sloty. Kazdy slot ma 32 bitu. Promenne typu byte, char,
short, int, boolean, float a reference zabiraji 1 slot, double a long
2 sloty.
No a kazda lokalni promenna je pak identifikovana cislem slotu.
Pro GC je dulezite to, ze prostor pro lokalni promenne existuje po
celou dobu vykonavani metody. Tzn., ze i kdyz opustime blok, v nemz
byla promenna deklarovana, neznamena to, ze je fyzicky (v pameti)
zrusena.
Jinymi slovy: ukazatel na objekt vytvoreny prikazem new Foo(null); je
ulozen v nekterem slotu a GC nepozna, ze jej muze dealokovat, protoze
nema informaci o tom, ktere sloty jsou aktualne pouzivane.
Principialne by bylo mozne, aby prekladac generoval pri opusteni bloku
instrukce pro nulovani vsech slotu, do nichz byly ulozeny promenne
lokalni v tomto bloku, ale sunovsky javac to nedela a rekl bych, ze to
nedelaji ani jine prekladace. Ve vyjimecnych pripadech by to sice
pomohlo, vetsinou by to vsak byl znacny overhead.
Z.T.
--
Zdenek Tronicek
Department of Computer Science and Engineering
Prague tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek
Cituji Dusan Zatkovsky msk.c...@gmail.com:
Ahoj.
Kedze som v jave novy a prechadzam do nej z C++, obcas sa pri programovani
pozastavim nad nejakou vecou, o ktorej viem, ze tak nejak funguje, ale aby
som mal pokojne spanie, musim si to osahat vlastnymi rukami.
Prave som napisal nejaku class-u, ktora obaluje urcite podclassy a poskutyje
urcitu ucelenu funkcionalitu. Tie jej podclassy rozne ukazuju sami do seba,
medzi sebou a tak podobne, proste o sebe vedia. A tak sa mi hlavou zacali
tocit otazky okolo garbage collectoru, platnosti objektov, case ich uvolnenia
z pamati a tak podobne.
A kedze som bol byvalym kolegom ( zdravim Ta Nhac :) ) presviedsany, ze reci
okolo javy a jej pamatovej nenazranosti su nezmysly, vyrobil som si rovno
maly test:
// obycajna class-a. Vypisom testujem cas jej odstranenia z pamati
// urdzuje odkaz na svoju nadradenu classu, pretoze obe budem nejak
// zapuzdrovat do jedneho celku a vyuzivaju medzi sebou svoje sluzby
public class Foo {
private Stuff stuff;
public Foo ( Stuff s ) {
this.stuff = s;
}
@Override
protected void finalize() {
System.out.println(finalize Foo);
}
}
// nejaka dalsia classa
public class Stuff {
public Foo foo = new Foo ( this );
@Override
protected void finalize() {
System.out.println(finalize Stuff);
}
}
public static void main(String[] args) {
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim Stuff, ten si vytvori dalsie Foo
Stuff s = new Stuff();
// f = null
}
// tu uz neexistuje ani Foo f, ani Stuff f, mozu byt zmazane
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
Thread.sleep(2000);
}
}
}
Kupodivu, vystupom programu bol nasledovny vypis:
start
aaa
aaa
aaa
...
Po pol hodine som to nechapajuc breakol.
Odkomentoval som to f = null
Vystup:
start
aaa
finalize Foo
aaa
aaa
aaa
...
Toto som nechal bezat par minut. Garbage collector ten Stuff nie a
nie zmazat.
Priznam sa, ze to uplne nechapem, pretoze za prvou zlozenou zatvorkou }
straca Stuff s platnost a nema dovod viac existovat v pamati.
Mna by zaujimalo, kedy ho gc uvolni, pretoze pokial bude mat Stuff 2GB, bude
aplikacia bezdovodne kradnut systemu 2GB pamati na bordel, ktory uz nikdy
nepouzije, boh vie na aku dlhu dobu.
Diky.
--
Dusan
Re: Kedy dojde k odstraneniu objektu?
Dusan Zatkovsky napsal(a): medzi sebou a tak podobne, proste o sebe vedia. A tak sa mi hlavou zacali tocit otazky okolo garbage collectoru, platnosti objektov, case ich uvolnenia z pamati a tak podobne. Pokud vím, poslední verze Javy používají generační garbage collector, popis je třeba tady: http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28aka_Ephemeral_GC.29 Když to zkrátím, tak z paměti je objekt uvolněn nejdřív po té, co na něj neexistuje odkaz, ale až po té, co daná generace objektů vyčerpá přidělený prostor, takže živé objekty jsou přesunuty do následující generace a ukazatel na konec zabraného prostoru je přesunut na začátek. Makub -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: ma...@ics.muni.cz Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Kedy dojde k odstraneniu objektu?
Ahoj,
podla mna uz z vasho testovania vyplynulo, ze gc si da namahu uvolnit
pamat co i len aj po jednom objekte - pripad ked ste nastavil f na null.
Ja som skusil nastavit s na null a dopadlo to podla ocakavania, gc
zrusil s aj obsiahnute s.foo. Povedat ze gc uvolnuje lokalne
premenne metod az po opusteni metody je hlupost, lebo potom pamatovo
narocne metody by zjedli pamat aj keby uvolnovali referencie.
A tak som skusil toto:
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim pole Stuff
Stuff[] theStuffs = new Stuff[100];
for (int i = 0; i theStuffs.length; i++) {
theStuffs[i] = new Stuff();
}
}
// tu uz neexistuje nic
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
try {
Thread.sleep(200);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Samozrejme ze gc pracoval a finalizoval. Trochu srandovny bol vystup
niekde v strede:
finalize Stuff
finalize Stuff
finalize StuffException in thread main java.lang.OutOfMemoryError:
Java heap space
at java.lang.ref.Finalizer.register(Unknown Source)
at java.lang.Object.init(Object.java:20)
at Foo.init(Foo.java:6)
at Stuff.init(Stuff.java:3)
at Stuff.main(Stuff.java:18)
finalize Foo
finalize Foo
Nebudem to analyzovat, lebo to nebol vhodny priklad, pole je predsa
nieco ine ako lokalne premenne. Spravny priklad by bol vytvorit tu
metodu s naozaj desattisickami lokalnych premennych(cez makro by to slo).
T.S.
Re: Kedy dojde k odstraneniu objektu?
Dobry den,
nedavno ma zaujimal podobny problem (ale v mojom pripade sa metoda
vzapati po local=null; skoncila) a uvazoval som nad tym, ci local=null
pomoze garbage collectoru alebo nie.
(http://stackoverflow.com/questions/473685) Spolu s diskutujucimi sme
sa zhodli, ze v mojom uvedenom pripade to nepomoze. Avsak to co pisete
dava zmysel, a ukazalo mi ze aj 'nullovanie' lokalnych premennych ma v
istych okrajovych pripadoch opodstatnenie. Pridal som priklad podla
vasho vysvetlenia do diskusie
(http://stackoverflow.com/questions/473685#583387). Vdaka za
prispevok.
S pozdravom,
-Peter Stibrany
// www.foglyn.com //
2009/2/24 Zdenek Tronicek troni...@fel.cvut.cz:
Dobry den,
myslim, ze pokud chcete porozumet tomu, proc nebyl objekt foo odstranen z
pameti, je nutne se trochu podivat na bytecode. V Jave funguje alokace
lokalnich promennych tak, ze pri VSTUPU DO METODY se na zasobniku naalokuje
prostor dostatecne velky na to, aby se tam vesly vsechny promenne
deklarovane v teto metode. Tento prostor se deli na tzv. sloty. Kazdy slot
ma 32 bitu. Promenne typu byte, char, short, int, boolean, float a reference
zabiraji 1 slot, double a long 2 sloty.
No a kazda lokalni promenna je pak identifikovana cislem slotu.
Pro GC je dulezite to, ze prostor pro lokalni promenne existuje po celou
dobu vykonavani metody. Tzn., ze i kdyz opustime blok, v nemz byla promenna
deklarovana, neznamena to, ze je fyzicky (v pameti) zrusena.
Jinymi slovy: ukazatel na objekt vytvoreny prikazem new Foo(null); je ulozen
v nekterem slotu a GC nepozna, ze jej muze dealokovat, protoze nema
informaci o tom, ktere sloty jsou aktualne pouzivane.
Principialne by bylo mozne, aby prekladac generoval pri opusteni bloku
instrukce pro nulovani vsech slotu, do nichz byly ulozeny promenne lokalni v
tomto bloku, ale sunovsky javac to nedela a rekl bych, ze to nedelaji ani
jine prekladace. Ve vyjimecnych pripadech by to sice pomohlo, vetsinou by to
vsak byl znacny overhead.
Z.T.
--
Zdenek Tronicek
Department of Computer Science and Engineering
Prague tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek
Cituji Dusan Zatkovsky msk.c...@gmail.com:
Ahoj.
Kedze som v jave novy a prechadzam do nej z C++, obcas sa pri programovani
pozastavim nad nejakou vecou, o ktorej viem, ze tak nejak funguje, ale aby
som mal pokojne spanie, musim si to osahat vlastnymi rukami.
Prave som napisal nejaku class-u, ktora obaluje urcite podclassy a
poskutyje
urcitu ucelenu funkcionalitu. Tie jej podclassy rozne ukazuju sami do
seba,
medzi sebou a tak podobne, proste o sebe vedia. A tak sa mi hlavou zacali
tocit otazky okolo garbage collectoru, platnosti objektov, case ich
uvolnenia
z pamati a tak podobne.
A kedze som bol byvalym kolegom ( zdravim Ta Nhac :) ) presviedsany, ze
reci
okolo javy a jej pamatovej nenazranosti su nezmysly, vyrobil som si rovno
maly test:
// obycajna class-a. Vypisom testujem cas jej odstranenia z pamati
// urdzuje odkaz na svoju nadradenu classu, pretoze obe budem nejak
// zapuzdrovat do jedneho celku a vyuzivaju medzi sebou svoje sluzby
public class Foo {
private Stuff stuff;
public Foo ( Stuff s ) {
this.stuff = s;
}
�...@override
protected void finalize() {
System.out.println(finalize Foo);
}
}
// nejaka dalsia classa
public class Stuff {
public Foo foo = new Foo ( this );
�...@override
protected void finalize() {
System.out.println(finalize Stuff);
}
}
public static void main(String[] args) {
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim Stuff, ten si vytvori dalsie Foo
Stuff s = new Stuff();
// f = null
}
// tu uz neexistuje ani Foo f, ani Stuff f, mozu byt zmazane
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
Thread.sleep(2000);
}
}
}
Kupodivu, vystupom programu bol nasledovny vypis:
start
aaa
aaa
aaa
...
Po pol hodine som to nechapajuc breakol.
Odkomentoval som to f = null
Vystup:
start
aaa
finalize Foo
aaa
aaa
aaa
...
Toto som nechal bezat par minut. Garbage collector ten Stuff nie a nie
zmazat.
Priznam sa, ze to uplne nechapem, pretoze za prvou zlozenou zatvorkou }
straca Stuff s platnost a nema dovod viac existovat v pamati.
Mna by zaujimalo, kedy ho gc uvolni, pretoze pokial bude mat Stuff 2GB,
bude
aplikacia bezdovodne kradnut systemu 2GB pamati na bordel, ktory uz nikdy
nepouzije, boh vie na aku dlhu dobu.
Diky.
--
Dusan
Re: Kedy dojde k odstraneniu objektu?
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[10];
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.
--
Zdenek Tronicek
Department of Computer Science and Engineering
Prague tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek
Cituji Tomas Studva tstu...@gmail.com:
Ahoj,
podla mna uz z vasho testovania vyplynulo, ze gc si da namahu
uvolnit pamat co i len aj po jednom objekte - pripad ked ste
nastavil f na null.
Ja som skusil nastavit s na null a dopadlo to podla ocakavania, gc
zrusil s aj obsiahnute s.foo. Povedat ze gc uvolnuje lokalne
premenne metod az po opusteni metody je hlupost, lebo potom pamatovo
narocne metody by zjedli pamat aj keby uvolnovali referencie.
A tak som skusil toto:
System.out.println(start);
{
// vytvorim Foo
Foo f = new Foo(null);
// vytvorim pole Stuff
Stuff[] theStuffs = new Stuff[100];
for (int i = 0; i theStuffs.length; i++) {
theStuffs[i] = new Stuff();
}
}
// tu uz neexistuje nic
while ( true ) {
System.out.println(aaa);
Runtime.getRuntime().gc();
try {
Thread.sleep(200);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Samozrejme ze gc pracoval a finalizoval. Trochu srandovny bol vystup
niekde v strede:
finalize Stuff
finalize Stuff
finalize StuffException in thread main java.lang.OutOfMemoryError:
Java heap space
at java.lang.ref.Finalizer.register(Unknown Source)
at java.lang.Object.init(Object.java:20)
at Foo.init(Foo.java:6)
at Stuff.init(Stuff.java:3)
at Stuff.main(Stuff.java:18)
finalize Foo
finalize Foo
Nebudem to analyzovat, lebo to nebol vhodny priklad, pole je predsa
nieco ine ako lokalne premenne. Spravny priklad by bol vytvorit tu
metodu s naozaj desattisickami lokalnych premennych(cez makro by to
slo).
T.S.
Re: Kedy dojde k odstraneniu objektu?
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[10];
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.
