[Java lista] array

Zsombor gzsombor at gmail.com
2009. Dec. 12., Szo, 11:54:40 CET


2009/12/12 eMeL <emel at emel.hu>

>
> > A tömb hosszának csökkentése nem olyan triviális, ha belegondolsz,
> > ugyanis a GC-nek is tudni kell róla. Vagy nyomonkövetnie az "aktuális"
> > hosszt és a memóriából lefoglalt hosszt, vagy pedig újra kéne
> > lefoglalnia manuálisan minden ilyen csökkentés esetén. S akkor meg
> > ugyanott vagyunk, mint voltunk :)
>
> Ezt nem látom be.
> Értelmezésemben (ha objektum tömb, akkor az utolsó elemeket NULL-ozza,
> egyébként érdektelen) és a tömb objektum hossz mezőjét módosítja.
> Arról volt szó, hogy a tömbnek foglalt terület megmarad, csak a hoszz
> csökken (kizárólag csökken). [*]
>
> Nem hinném, hogy a Jáva objektumok nem egyszerűen egy memória pointert
> kapnak a lefoglalt terĂĽletre Ă©s csak a GC/memoria_menedzser ismeri a
> lefoglalt terület valódi hosszát [mint a C heapnál].
> Ugyanis az objektumnak nem sok köze van ahhoz, hogy pl. erőforrás
> optimalizálás okból [**] nagyobb területet foglaltak neki mint amit kért.
>
>
Igen, a GC ismeri a lefoglalt memória méretét, és pont a tomb.length
mezőjében tárolja is azt. Persze lehetne arról fantáziálni, hogy milyen jó
lenne, ha le tudnám származtatni a tömböt, s egy plusz mezőt is hozzácsapni,
vagy hogy alapból legyen egy 'length' és egy 'currentlyUsedLength' mező, de
úgy vélem, ez egy nehezen eladható ötlet lenne, hogy egy tömbhöz tároljunk 2
darab hossz értéket. Amiből 1 ráadásul semmire se használható. Arról nem is
beszélve, hogy ha a tömb mérete változtatható lenne, akkor egy ilyen kódot a
hotspot nem tudna optimalizálni :

for (int i=0;i<tomb.length;i++) {
   System.out.println(tomb[i]);
}

Ha a tömb mérete nem változik, akkor a tomb[i] hívásnál sosem kell
ellenőrizni, hogy nem próbálkozunk egy túl nagy index pozícióra hivatkozni.

Zs




> [**] pl. 16-32-x bytehatárra illeszt mindent vagy a kiválasztott szabad
> memória töredék kiosztásakor úgy dönt nem érdemes még ketté hasítani,
> mert a maradék túl apró lenne, stb.
>
> [*] természetesen egy segédváltozóval egyszerűen kikerülöm a problámát,
> de tisztább-szárazabb (és OOP-bb szemléletű), ha a Tomb.length-t
> használom egy hasznalthosszTomb független vátozó helyett.
>
> eMeL
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20091212/247c7eab/attachment.html 


További információk a(z) Javalist levelezőlistáról