[JAVA] Opruimen gereserveerd geheugen

[koli-man]

Ik heb een even een simpele declaratie gemaakt van een tabel met daarin een aantal objecten. Nou vraag ik me af, als je bijvoorbeeld in c++ delete gebruikt...Hoeft dat niet in Java. Ik heb daar wel op gezocht maar ik vond niet zo'n concreet voorbeeld

Java:

  public Filiaal(String hetAdres, String hetTelnummer,int hetaantalpersonen)
   {
      Adres = hetAdres;
      Telefoon = hetTelnummer;
      thePersoon = new Object[hetaantalpersonen];
   }

   public void VoegMedewerkerToe(Medewerker deMedewerker)
   {
      thePersoon[Aantalklanten+Aantalwerknemers]=deMedewerker;
      Aantalwerknemers++;
   }

   public void VerwijderMedewerker(Medewerker deMedewerker)
   {
      thePersoon[Aantalklanten+Aantalwerknemers]    //hier zou de geheugenplaats opgeruimd moeten worden 
      Aantalwerknemers--;
   }
 

Op de plaats waar het commentaar staat..tja het spreekt voor(hoop ik)
Maar ik vond geen concreet voorbeeld door zoeken

alvast bedankt

[SWfreak]

Das nou het makkelijke aan Java: je hoeft niet zelf je geheugen te deleten. Dat doet de garbage collector voor je. Die checkt om de zoveel tijd over er geheugen is waar niet meer naar gerefereerd wordt en delete dat dan zelf. Daarom zijn er ook geen destructors in Java.
Als je toch per se dat geheugen vrij wil maken kun je thePersoon[..] = null; zetten en vervolgens System.gc() aanroepen. Dit start de garbage collector en zal de rommel opruimen

[ Voor 14% gewijzigd door SWfreak op 14-05-2003 11:07 . Reden: meer info ]

[machiel]

Je zou het array met personen beter als HashSet kunnen implementeren.

PHP:

public Filiaal(String hetAdres, String hetTelnummer,int hetaantalpersonen) 
   { 
      Adres = hetAdres; 
      Telefoon = hetTelnummer; 
      Set thePersoon = new HashSet()
   } 

   public void VoegMedewerkerToe(Medewerker deMedewerker) 
   { 
      thePersoon.add(deMedewerker);
   } 

   public void VerwijderMedewerker(Medewerker deMedewerker) 
   { 
        thePersoon.remove(deMedewerker);
   }

[Verwijderd]

Irritant, dat Java het zelf opruimd. Java moet met zijn poten van mij mooie memory leaks afblijven

Heb ik veel moeite voor moeten doen

[ Voor 18% gewijzigd door Verwijderd op 14-05-2003 11:43 ]

[koli-man]

SWfreak schreef op 14 May 2003 @ 11:05:
Das nou het makkelijke aan Java: je hoeft niet zelf je geheugen te deleten. Dat doet de garbage collector voor je. Die checkt om de zoveel tijd over er geheugen is waar niet meer naar gerefereerd wordt en delete dat dan zelf. Daarom zijn er ook geen destructors in Java.
Als je toch per se dat geheugen vrij wil maken kun je thePersoon[..] = null; zetten en vervolgens System.gc() aanroepen. Dit start de garbage collector en zal de rommel opruimen

Ok. Mijn vraag is wel beantwoord thxn

[Glimi]

koli-man schreef op 14 May 2003 @ 11:00:
Ik heb een even een simpele declaratie gemaakt van een tabel met daarin een aantal objecten. Nou vraag ik me af, als je bijvoorbeeld in c++ delete gebruikt...Hoeft dat niet in Java. Ik heb daar wel op gezocht maar ik vond niet zo'n concreet voorbeeld

C++ != Java. Java draait binnen een VM een heeft dus garbage collection nodig om zijn eigen processen te kunnen garanderen dat er niet geknoeit wordt binnen de VM met geheugen (en dat is wel makkelijk als je in een sandbox wilt werken)

Waarom maak je eigenlijk niet gebruik van de remove method van List? Dan heb je al dat array gewauwel niet waar je nu mee bezig bent
Verder, als je denkt veel toe te voegen en te verwijderen, overweeg dan een LinkedList

[koli-man]

Glimi schreef op 14 mei 2003 @ 13:44:
[...]

C++ != Java. Java draait binnen een VM een heeft dus garbage collection nodig om zijn eigen processen te kunnen garanderen dat er niet geknoeit wordt binnen de VM met geheugen (en dat is wel makkelijk als je in een sandbox wilt werken)

Waarom maak je eigenlijk niet gebruik van de remove method van List? Dan heb je al dat array gewauwel niet waar je nu mee bezig bent
Verder, als je denkt veel toe te voegen en te verwijderen, overweeg dan een LinkedList

Een linked list was inderdaad beter geweest, of een uitbreidbaar array kon ook nog. Als ik het echt goed had willen doen had ik Een Iteraror - Pattern geconstrueerd, maar dit heb ik gisteren - avond in moeten leveren en tja...de tijdsdruk he

[Glimi]

koli-man schreef op 14 mei 2003 @ 13:49:
Een linked list was inderdaad beter geweest, of een uitbreidbaar array kon ook nog. Als ik het echt goed had willen doen had ik Een Iteraror - Pattern geconstrueerd, maar dit heb ik gisteren - avond in moeten leveren en tja...de tijdsdruk he

*kuch*list.iterator() *kuch*

[koli-man]

Glimi schreef op 14 May 2003 @ 13:54:
[...]

*kuch*list.iterator() *kuch*

Wat bedoel je met die kuch?

[TrendKiller]

SWfreak schreef op 14 May 2003 @ 11:05:
Das nou het makkelijke aan Java: je hoeft niet zelf je geheugen te deleten. Dat doet de garbage collector voor je. Die checkt om de zoveel tijd over er geheugen is waar niet meer naar gerefereerd wordt en delete dat dan zelf. Daarom zijn er ook geen destructors in Java.
Als je toch per se dat geheugen vrij wil maken kun je thePersoon[..] = null; zetten en vervolgens System.gc() aanroepen. Dit start de garbage collector en zal de rommel opruimen

mierenneuken: je kan nooit de garbage-collector forcen om geheugen vrij te maken. Zelfs al roep je System.gc() aan, dan vraag je in feite of de GC wil lopen, en de GC zal zelf wel beslissen of hij al dan niet loopt.

[Verwijderd]

Trendkiller schreef op 14 May 2003 @ 14:01:
[...]


mierenneuken: je kan nooit de garbage-collector forcen om geheugen vrij te maken. Zelfs al roep je System.gc() aan, dan vraag je in feite of de GC wil lopen, en de GC zal zelf wel beslissen of hij al dan niet loopt.

Inderdaad, het aanroepen van System.gc() is volgens mij ook vrij zinloos. Wanneer gebruik je System.gc() dan? Nooit!
Zodra je een object verwijzing weer null maakt gaat de garbage collector zelf wel de boel opruimen, daarom zijn er dus ook geen destructors in Java.
Ben benieuwd wat mbravenboer er over te zeggen heeft...:)

[Glimi]

koli-man schreef op 14 mei 2003 @ 13:57:
Wat bedoel je met die kuch?

Dat het patroon al in Java zit. Hoogstens 3 minuten werk

Verwijderd schreef op 14 mei 2003 @ 14:08:
Zodra je een object verwijzing weer null maakt gaat de garbage collector zelf wel de boel opruimen, daarom zijn er dus ook geen destructors in Java.
Ben benieuwd wat mbravenboer er over te zeggen heeft...:)

Zou ik ook mogen? Ik zal es proberen iets over GC te vertellen.

Normaal gaat de GC alleen runnen als het nodig is. Dit omdat GC gewoon tijd kost en waarom de tijd nemen als het niet nodig is? In de tijd dat GC draait, kan nl. het programma niet door werken

Waarneer gaat de GC nou draaien? Heel simpel eigenlijk. Als er zoveel objecten op de heap staan, dat er een bepaalde grens overschreden is qua ruimte. De GC zal dan beginnen met draaien en vanuit z'n variabelen op de stack & static geheugen ruimte gaan kijken, welke objecten hij allemaal kan bereiken. Die objecten worden dan gemarkeerd. Als dat voltooid is, dan worden alle niet gemarkeerde objecten verwijderd.

Dat is allemaal goed en wel, maar er zitten dan wel gaten in het geheugen, waar niets staat. Bij allocatie moet dan vervolgens gezocht gaan worden waar nog ruimte vrij is (en dat is kostbaar) of er moet op het eind gealloceerd worden, maar dan hebben we niets opgeschoten.

Wat de GC meestal doet, is de heap opdelen in twee delen. Als dan slaat hij de verwijdering van de niet-gemarkeerde objecten over, maar copieert de wel-gemarkeerde objecten naar het niet gebruikte deel van de heap. Dan is het gelijk gecomprimeerd
Dit heet een stop-and-copy aloritme Het markeer gedeelte heet Mark-and-Sweep. Stop and copy is dus een optimalisatie van Mark-and-Sweep.

Een eigenschap van programma's is ook dat de objecten vaak uit twee groepen bestaan
1) Objecten die ontzettend kort leven. Dit is een grote groep
2) Objecten die het hele programma door leven. Dit is een erg kleine groep.

Als het programma in een fase is gekomen dat het uit lang levende objecten bestaat, dan worden deze de hele tijd voor jan lul heen en weer gekopieerd.
Dan wordt er vaak geswitched naar generational-collectors. Generational houdt in dat de heap onderverdeeld wordt in verschillende delen. Je classificeerd de objecten dan naar hun leeftijd (gemeten in overleefde GC run's). Hoe hoger de leeftijd, des de hoger de subgroep waar ze in zitten.

De GC draait dan op elke groep apart, zodat de 'jongste' objecten vaker geGC'ed worden dan de ouderen.
Hierdoor verspil je niet de hele tijd de moeite om de oude objecten te controleren en heen en weer te copieeren.
Dit is een generational algoritme.

Volgens mij was dit ongeveer alles wat ik verteld had in m'n presentatie pas PDF kun je vinden @ http://glimi.dezeserver.nl/

[reddog33hummer]

Verwijderd schreef op 14 mei 2003 @ 14:08:
[...]

Inderdaad, het aanroepen van System.gc() is volgens mij ook vrij zinloos. Wanneer gebruik je System.gc() dan? Nooit!
Zodra je een object verwijzing weer null maakt gaat de garbage collector zelf wel de boel opruimen, daarom zijn er dus ook geen destructors in Java.
Ben benieuwd wat mbravenboer er over te zeggen heeft...:)

Het aanroepen van System.gc() kan heel nuttig zijn waneer je in een algoritme weet dat iets gaat komen wat veel geheugen nodig heeft.

Waar je wel mee moet opassen is dat je het niet aanroept wanneer je met meerdere threads werkt. De oude Sun VM's stopte gewoon de executie, garbage collect en gingen dan pas verder. Op zich is dat normaal niet een probleem maar waneer dit gebeurt tijdens dataacties... ouh.

Dennis26 schreef op 14 mei 2003 @ 14:08:
Zodra je een object verwijzing weer null maakt gaat de garbage collector zelf wel de boel opruimen, daarom zijn er dus ook geen destructors in Java.
Ben benieuwd wat mbravenboer er over te zeggen heeft...:)

En finalize dan ? Kan je gebruiken als vervanging van de destructor.

Denk er wel aan dat als je java koppelt met andere systemen -> RMI, sockets, C++ code je er aan moet denken deze op te ruimen. De garbage collector is daar soms niet al te vroeg bij.

[ Voor 26% gewijzigd door reddog33hummer op 14-05-2003 18:18 ]

[KompjoeFriek]

@Glimi:
Je hebt voor mij perfect uitgelegt waarom Java nou eigelijk langzamer is dan andere programeertalen (is de Garbage-collector echt niet uit java te slopen?)

@koli-man:
je kunt de plaats simpel weg leeg maken door er null in te zetten (teminste, dat leren ze ons op school)
dus de regel met comment wordt dan:

Java:

thePersoon[Aantalklanten+Aantalwerknemers] = null;

[ACM]

KompjoeFriek schreef op 14 May 2003 @ 18:34:
@Glimi:
Je hebt voor mij perfect uitgelegt waarom Java nou eigelijk langzamer is dan andere programeertalen (is de Garbage-collector echt niet uit java te slopen?)

Waarom is Java slomer door de garbage collector

Er staat juist uitgelegd dat ie zo min mogelijk wordt aangeroepen. Java zal eerder slomer zijn doordat het een geinterpreteerde omgeving is die pas op het laatste moment enkele optimalisaties uit kan voeren, terwijl C++/C tijdens de compilatie al zwaar en langdurig geoptimaliseerd kan worden.
Verder zal de verplichte controle op de array-grootte's en dergelijke meespelen, het feit dat het een OO systeem is maakt het ook niet sneller en de onkunde van sommige mensen met Java is ook niet bevordelijk (continue een String appenden, ipv eerst alles in een StringBuffer zetten bijv) etc.

[Glimi]

reddog33hummer schreef op 14 May 2003 @ 18:15:
En finalize dan ? Kan je gebruiken als vervanging van de destructor.

Denk er wel aan dat als je java koppelt met andere systemen -> RMI, sockets, C++ code je er aan moet denken deze op te ruimen. De garbage collector is daar soms niet al te vroeg bij.

Finalize is geen destructor omdat na een finalize het object niet wordt opgeruimt!
Stel er draait een gc een ronde en heeft het object A niet gemarkeerd. Object A is dus niet gerefeerd en nog nooit gefinalized() en mag dus pas destructed worden als finalize() aangeroepen is. De GC roept eerst finalize() aan op het object. Dan houd z'n ronde op.

Maar stel, in object A z'n finalize staat dit:

Java:

public void finalize() {

   _member.referTo( this );
}

Waarbij door de finalize A opeens weer gerefeerd gaat worden. De volgende ronde zal A dan niet gedestruct worden maar gewoon gemarkeerd en gecopyed naar de andere heap.

Dat is nou het kritieke verschil met een destructor.
Detail is trouwens dat dit maar 1x kan De finalize() zal altijd maar 1x aangeroepen worden

KompjoeFriek schreef op 14 May 2003 @ 18:34:
@Glimi:
Je hebt voor mij perfect uitgelegt waarom Java nou eigelijk langzamer is dan andere programeertalen (is de Garbage-collector echt niet uit java te slopen?)

Uhm dan heb je me toch niet helemaal begrepen Java's garbage collection scheelt echt niet zoveel tijd als hij gewoon lekker dmv een generational collector werkt. Sterker nog, er is dan te garanderen dat hij maximaal t tijd over z'n garbage run doet

En NEE GC kan niet uit in java. Reden is heel simpel en al genoemd in deze thread

Glimi schreef op 14 May 2003 @ 13:44:
C++ != Java. Java draait binnen een VM een heeft dus garbage collection nodig om zijn eigen processen te kunnen garanderen dat er niet geknoeit wordt binnen de VM met geheugen (en dat is wel makkelijk als je in een sandbox wilt werken)

[hobbit_be]

DE truuk in mijn prille ervaring met java is zoveel mogelijk het gebruik van ... new X te vermijden. Pools, BUffers, Hergebruik zijn echt cruciaal voor een snelle Java App. Aangezien de GC , eens ie werkt wel traag is, probeer je ervoor te zorgen dat ie het bijna nooit hoeft te doen. Gek is dit niet want elke goede C/C++ doet net hetzelfde voor dingen die belangrijk zijn. In een topic een tijdje terug probeerde we een snelle replace voor een string toe te passen. Alhoewel het algoritme erg belangrijk was bleek een andere factor nog belangrijker: het vermijden van new, copy van object (vooral arrays). De NIO lost wel sommige van die problemen op. Je moet een beetje 'ik ben een game aan het maken' voor een responsive app. wel jammer dat delete niet bestaat alhoewel het dan eerder 'release' zou moeten heten die de GC forceert op dat punt te clearen (als dat logisch is. en if not throw a non-releasable error ofzo. Goed voor critical code... mbravenboer gaat dit in Java 3.0 zitten ? , ik kan alvast niet wachten op 1.5... for ( : ) rulez ...)