[Java] Moet er een delete statement komen?

[Robtimus]

Ik programmeer al een tijdje in Java, en vind het memory management (de garbage collector) enorm fijn. Alleen ik ben pas geleden ook wat in C(++) gaan doen, en zelf bepalen wanneer een stuk geheugen wordt gedealloceerd vind ik soms toch wel prettig; je hebt wat meer controle over je programma.

Daarom wil ik een discussie starten: zou Java een delete statement moeten krijgen?

Daarmee bedoel ik niet dat je zelf AL het geheugenbeheer moet doen, maar optioneel kan zeggen dat een stuk geheugen NU vrijgemaakt moet worden, zoals in bv C++.
Natuurlijk alleen als de reference count 0 is, en als je de delete niet aanroept doet de GC gewoon zijn werk (ook als de reference count nog niet 0 is).

Ik weet wel dat er System.gc() is, maar voor zover ik weet hoeft die niet direct te gaan lopen, maar geef je slechts een indicatie dat je het nu wilt.

Wat vindt GoT?

[Zoijar]

Je kan een "pointer" gewoon null toekennen in java, dan wordt het in de volgende gc cycle gewist

[ Voor 9% gewijzigd door Zoijar op 30-03-2004 22:49 ]

[Verwijderd]

Ik vind het best zo. Als ik een realitme applicatie moet maken, dan is het belangrijk dat ik mijn eigen geheugenbeheer doe (wil geen gezeur met plotselinge gc acties), dus dat doe ik liever in C++.

Als het niet realtime hoeft, geniet ik liever van de gemakken van de garbage collector.

[ Voor 9% gewijzigd door Verwijderd op 30-03-2004 22:50 ]

[.oisyn]

Deterministic finalization zou wel fijn zijn though
C++ kent dit: als een object op de stack buiten scope gaat, dan wordt automatisch de destructor aangeroepen. .Net krijgt dit ook, en je kunt er hele mooie exception-safe code mee schrijven zonder je code vol te peperen met try/finally's

(Ik mis dat try/finally overigens wel weer in C++)

Natuurlijk alleen als de reference count 0 is, en als je de delete niet aanroept doet de GC gewoon zijn werk (ook als de reference count nog niet 0 is).

Maar hoe doe je dan een delete? Je hebt dan een referentie nodig naar een object, en dus is de refcount nooit 0 Hij zou dan 1 moeten zijn, maar een gc systeem werkt echter niet met simpele reference counting (aangezien dit het cyclic references probleem heeft)

[ Voor 40% gewijzigd door .oisyn op 30-03-2004 22:57 ]

[Robtimus]

Zoijar schreef op 30 maart 2004 @ 22:49:
Je kan een "pointer" gewoon null toekennen in java, dan wordt het in de volgende gc cycle gewist

Ja maar dus niet DIRECT. En dat is nu waar de discussie over gaat (deterministic finalization dus). Want je weet nooit wanneer die volgende GC cycle is.

[Robtimus]

.oisyn schreef op 30 maart 2004 @ 22:55:
[...]

Maar hoe doe je dan een delete? Je hebt dan een referentie nodig naar een object, en dus is de refcount nooit 0 Hij zou dan 1 moeten zijn, maar een gc systeem werkt echter niet met simpele reference counting (aangezien dit het cyclic references probleem heeft)

Ik hou me niet bezig met de details, dat laat ik wel aan Sun over

[wasigh]

als je zorgt dat je objecten niet lang leven blijven ze in de young sector van de garbage collector. Op het moment dat ze langer blijven bestaan verhuizen ze naar de tenured sector. Opruimen uit de young sector gaat ongeveer een factor 10 sneller dan uit de tenured

als je je applicatie opstart met -XX:+printGCDetails krijg je een overzicht van de garbage collector, hoeveel geheugen hij bevrijd en hoelang dat heeft geduurd.

Je kunt ook met de -Xaprof [class]
bekijken hoeveel ruimte elke class in het geheugen gebruikt en kijken wat je moet optimalisren

als je weet hoeveel ruimte je app nodig heeft kun je hem natuurlijk ook een grotere heap geven om te zorgen dat de Garbage Collector niet in actie hoeft te komen om ruimte gebrek te voorkomen,

dat kan met bijvoorbeeld:java -Xms64m [class]
verder kun je nog verschillende soorten van Garbage Collection aanzetten en natuurlijk object reuse e.d. gebruiken.

(deze info komt uit 1 van mijn boeken, niet getest )

[Macros]

De GC wordt alleen automatisch aangeroepen als er geen geheugen genoeg is om nieuwe objecten te alloceren. Wat je dus zou kunnen doen, is al je objecten aan het begin van je programma te alloceren. Dan zal de GC nooit worden aangeroepen omdat je nooit meer geheugen alloceerd.

[whoami]

Macros schreef op 30 maart 2004 @ 23:27:
De GC wordt alleen automatisch aangeroepen als er geen geheugen genoeg is om nieuwe objecten te alloceren. Wat je dus zou kunnen doen, is al je objecten aan het begin van je programma te alloceren. Dan zal de GC nooit worden aangeroepen omdat je nooit meer geheugen alloceerd.

Ik weet niet hoe de GC in Java geimplementeerd is, maar dit lijkt me sterk. Ik kan moeilijk geloven dat de GC pas in werking treedt als er geen geheugen meer beschikbaar is voor een allocatie. Dit zou normaal een OutOfMemoryException oid moeten geven.
In .NET wordt de GC op bepaalde tijdstippen aangeroepen door de CLR. Wanneer hij aangeroepen wordt, bepaald de CLR adhv het allocatie-gedrag van je applicatie, maar het is zeker niet zo dat hij enkel wordt aangeroepen (of iedere keer wordt aangeroepen) als je geheugen alloceert. Dat zou behoorlijk inefficiënt zijn.

Ik heb net even wat gelezen over garbage collection in Java, en ik vind nergens terug dat de GC wordt aangeroepen als er een allocatie plaatsvindt.

Over het vrijgeven van resources: je kan natuurlijk een Dispose method implementeren waar je resources vrijgeeft enzo. Het geheugen wordt dan wel nog niet vrijgegeven (aangezien de GC dat doet), maar is dat zo erg op machines met >128mb geheugen?
Het enige nadeel van managed geheugen beheer is, imho, de vertraging die optreedt als er geheugen vrijgegeven wordt: de heap wordt namelijk gecompacted, en dat vergt wel wat tijd.
(Echter, het compacten van de heap gebeurt zowel in .NET als bij Java niet bij iedere collection van de GC, dus dat valt ook nogal mee).

[kasper_vk]

Volgens mij is een delete-statement practisch gewoon niet haalbaar: de compiler of de VM zal op de een of andere wijze zeker moeten weten dat er naar het object dat je delete ook echt geen andere referencies meer zijn.
En aangezien Sun (volgens mij) niet in de Java specificatie heeft gespecificeerd hoe de GC werkt, zou dat veel omslachtiger kunnen zijn dan ff de reference count te bekijken.

Ik dacht overigens (geen ervaring) dat je in .NET de GC kan aanroepen en dat dat dan wel direct gebeurt; daar zou ik idd wel voordelen in zien.

edit:
Eigelijk juist heel erg on-topic:

Ik denk dat je je als mens niet moet bemoeien met geheugenbeheer, dat kan een (goed gemaakte) VM bij 99,9% van de programmeurs echt veel beter. In mijn ogen is een delete-statement dus niet wenselijk.

[ Voor 8% gewijzigd door kasper_vk op 31-03-2004 09:33 ]

[whoami]

Je kan idd zelf een collectie forceren van de garbage collector (in .NET en in Java) door GC.Collect() (in .NET, de syntax in Java zal wel gelijkaardig zijn) aan te roepen.
Dit is echter niet bevorderlijk voor de performance van je applicatie.

De GC in Java werkt volgens mij met een mark-and-sweep implementatie. (In de eerste versie's van Java toch).
De .NET GC is ook een mark-and-sweep collector.

[aphx]

Nee, ik denk niet dat dat wenselijk is. Het is niet voor niets dat het er niet in zit.

Ik lees trouwens de laatste tijd wel steeds meer over pluggable gc, vooral bij PDA's (micro edition) maar volgens mij ook al bij normale JVM's (Hotspot??) maar ik kan zo even geen link vinden.

[Glimi]

whoami schreef op 31 maart 2004 @ 08:56:
Ik weet niet hoe de GC in Java geimplementeerd is, maar dit lijkt me sterk. Ik kan moeilijk geloven dat de GC pas in werking treedt als er geen geheugen meer beschikbaar is voor een allocatie. Dit zou normaal een OutOfMemoryException oid moeten geven.
In .NET wordt de GC op bepaalde tijdstippen aangeroepen door de CLR. Wanneer hij aangeroepen wordt, bepaald de CLR adhv het allocatie-gedrag van je applicatie, maar het is zeker niet zo dat hij enkel wordt aangeroepen (of iedere keer wordt aangeroepen) als je geheugen alloceert. Dat zou behoorlijk inefficiënt zijn.
(...)

Je begrijpt Macros verkeerd. De meeste Java implementaties van een GC die gaan inderdaad pas lopen als er een bepaalde grens qua geheugengebruik is bereikt. Het wil dus niet zeggen dat bij elke allocatie gekeken wordt. De GC is vaak geimplementeerd als een losse thread die af en toe eens kijkt. Dit houdt ook in dat de GC best tijdens een programma niet kan gaan lopen omdat het helemaal niet nodig is en dus helemaal geent ijd inneemt tijdens het programma.

wasigh schreef op 30 maart 2004 @ 23:11:
als je zorgt dat je objecten niet lang leven blijven ze in de young sector van de garbage collector. Op het moment dat ze langer blijven bestaan verhuizen ze naar de tenured sector. Opruimen uit de young sector gaat ongeveer een factor 10 sneller dan uit de tenured
(...)

Je boek heeft gelijk

.oisyn schreef op 30 maart 2004 @ 22:55:
Deterministic finalization zou wel fijn zijn though
C++ kent dit: als een object op de stack buiten scope gaat, dan wordt automatisch de destructor aangeroepen. .Net krijgt dit ook, en je kunt er hele mooie exception-safe code mee schrijven zonder je code vol te peperen met try/finally's

(Ik mis dat try/finally overigens wel weer in C++)

Ik stel het me even voor hoor, maar bijvoorbeeld een final reference lokaal gedeclareerd wordt, dan ook opgeruimd na het aanroepen van de methode. Dan wordt ook het gealloceerde stuk geheugen vrij gegeven in het geheugen, waarmee dus een 'gat' in het tobe-allocatiegebied (creatief woord vind je niet?) komt te staan.
Hoe vul je dit gat op? De GC doet namelijk ook compression om zo juist geen gaten in het tobe-allocatiegebied te laten vallen en om zo snel geheugen te kunnen alloceren.

Nu kun je wel zeggen dat er dan een aanpassing van het allocatiealgoritme kan plaats vinden, maar dat vind ik niet echt realistisch. SUN kiest er juist altijd voor om de oude VM's compatible te laten zijn. En deze zouden dan flink inefficienter worden, of je krijgt weer zo'n gare switch

Maar hoe doe je dan een delete? Je hebt dan een referentie nodig naar een object, en dus is de refcount nooit 0 Hij zou dan 1 moeten zijn, maar een gc systeem werkt echter niet met simpele reference counting (aangezien dit het cyclic references probleem heeft)

For the record: Java VM's doen vaak generation mark-and-sweep en stop and copy.

[Macros]

Er zijn Java compilers die naar native code compilen waarbij veel nadelen van de GC zijn vermindered omdat ze proberen de objecten op de stack te allocaten en nog meer andere trucjes. Als je echt een snelle app wil maken, dan moet je daar eens naar kijken.

[.oisyn]

Glimi schreef op 31 maart 2004 @ 10:01:
Ik stel het me even voor hoor, maar bijvoorbeeld een final reference lokaal gedeclareerd wordt, dan ook opgeruimd na het aanroepen van de methode. Dan wordt ook het gealloceerde stuk geheugen vrij gegeven in het geheugen, waarmee dus een 'gat' in het tobe-allocatiegebied (creatief woord vind je niet?) komt te staan.
Hoe vul je dit gat op? De GC doet namelijk ook compression om zo juist geen gaten in het tobe-allocatiegebied te laten vallen en om zo snel geheugen te kunnen alloceren.

Nu kun je wel zeggen dat er dan een aanpassing van het allocatiealgoritme kan plaats vinden, maar dat vind ik niet echt realistisch. SUN kiest er juist altijd voor om de oude VM's compatible te laten zijn. En deze zouden dan flink inefficienter worden, of je krijgt weer zo'n gare switch

Sorry maar ik snap geen zak van wat je nou precies bedoelt
Deterministic finalization is dat je een destructor call hebt of some sort (finalize () is dat in java geloof ik?) waarvan het moment dat ie wordt aangeroepen determistisch is, dus je weet wanneer hij aangeroepen gaat worden. Dit in tegenstelling tot de huidige implementatie, waar de call pas gedaan wordt als het object daadwerkelijk wordt opgeruimd door de GC.

In deze destructor kun je code kwijt die opruimwerk doet. Dit geldt typisch voor lokale objecten op de stack: zodra ze uit scope gaan wordt de destructor aangeroepen, en kun je het opruimwerk gaan doen. Dit betekent bijvoorbeeld het sluiten van een file of netwerkconnectie, of de rollback van een bepaalde operatie als iets fout is gegaan (wanneer er dus een exception wordt gegooid). Dit is code die momenteel niet in de finalize () methode van een object past, omdat je simpelweg niet zeker weet wanneer hij wordt aangeroepen. Met deterministic finalization, en kun je code in de destructor kwijt (en hoef je niet je code vol te peperen met try/finally statements)

Het is een techniek die in C++ heel erg veel gebruikt wordt (hoewel dat ook wel een beetje komt omdat het geen try/finally kent), en hiermee schrijf je bijna op een automatische manier exception-safe code.

Het daadwerkelijk vrijgeven van het geheugen hoeft dus niet per se, dat is helemaal niet het doel van de techniek

[bille]

Als ik mag vragen: in welke situatie zou je willen dat een stuk geheugen NU wordt vrij gemaakt als je helemaal geen zeggenschap hebt over waar een instantie van een object in het geheugen gealloceerd wordt?

Bij gebruik van JAVA is het juist helemaal NIET van belang waar welk object wordt neergezet in het geheugen.. en zou ook niet uit hoeven maken, zolang het maar werkt. De geheugenallocatie algoritmen die in de JVM van SUN zitten zij vrij efficient dus dat zou geen argument zijn om 'het zelf te willen doen'. En er zijn wellicht nog een aantal JVM's op de markt die het echt OPTIMAAL doen, desnoods bouw je er zelf een als je denkt dat je het beter kunt.

Een 'delete' statement als onderdeel van de taal zal er dus nooit komen, dat kan ik nu wel voorspellen. Hooguit komt er een efficientere JVM met een beter geheugenmanagement algoritme. Sun kiest met JAVA juist voor een scheiding tussen taal en systeemresource management.. het toelaten van een delete statement in de taal zou dit fundamentele uitgangspunt ondermei?nen dus komt het er niet

en hoef je niet je code vol te peperen met try/finally statements

btw: het exceptionhandling mechanisme in JAVA is er niet geheel voor bedoeld om alleen nullpointers op te vangen, het kan wel, maar als je daar afhankelijk van bent dan heb je gewoon niet goed geprogrammeerd, dan had je bijv. het NULL Object pattern beter moeten toepassen . Een Exception is gewoon een uitzonderlijke state in je programma, dat is bijv. wanneer je verwacht dat je een connectie met je db hebt, maar die wordt onverwacht verbroken. Dat is een functionele exceptie daar een nullpointer EIGELIJK (OO gezien dan, want dan zou je geen nullpointer hebben, maar een NULL object) geen functionele exceptie is. * bille gebruikt et ook wel hoor, daar niet van.. maar tis eigelijk niet netjes.
my 2 cents

[ Voor 35% gewijzigd door bille op 31-03-2004 20:49 ]

[Count]

Ik denk dat het trage parsen/executeren van het delete statement in Java het eventuele snelheidsvoordeel tov een complete garbagecollection cycle sowieso al nihil maakt.

[.oisyn]

bille schreef op 31 maart 2004 @ 20:40:
Als ik mag vragen: in welke situatie zou je willen dat een stuk geheugen NU wordt vrij gemaakt als je helemaal geen zeggenschap hebt over waar een instantie van een object in het geheugen gealloceerd wordt?

Dat zeg ik helemaal niet, het gaat niet om het vrijgeven van geheugen, maar om het aanroepen van destructors. En wat heeft het te maken waar het object wordt gealloceerd
Of was dit niet een reactie op die van mij? (je quote mij verderop namelijk wel, vandaar )

btw: het exceptionhandling mechanisme in JAVA is er niet geheel voor bedoeld om alleen nullpointers op te vangen, het kan wel, maar als je daar afhankelijk van bent dan heb je gewoon niet goed geprogrammeerd,

Eens, maar dat beweer ik ook helemaal niet. Ik heb het meer over abnormale toestanden die elk moment op kunnen treden, dus idd het wegvallen van een db of netwerk-connectie, om maar een voorbeeld te noemen. En in die gevallen wil je juist bepaald error-recovery werk gaan doen. Je zou bijvoorbeeld bij het wegvallen van een netwerkconnectie de file die je aan het downloaden was kunnen verwijdern.

Dat is een functionele exceptie daar een nullpointer EIGELIJK (OO gezien dan, want dan zou je geen nullpointer hebben, maar een NULL object) geen functionele exceptie is.

Ik heb zoiets dan ook totaal niet beweerd. Exception safe programming betreft niet puur en alleen de exceptions die gegooid worden door programmeursfouten, maar alle soorten exceptions (en in het specifiek abnormale toestanden in je programma door iets wat niet zou moeten gebeuren)

[bille]

Of was dit niet een reactie op die van mij?

neej was vraag voor TS gezien hij aangeeft dat ie een delete statement wel zou willen.

[Glimi]

.oisyn schreef op 31 maart 2004 @ 20:25:
Sorry maar ik snap geen zak van wat je nou precies bedoelt
(...)
Het daadwerkelijk vrijgeven van het geheugen hoeft dus niet per se, dat is helemaal niet het doel van de techniek

Als het vrijgeven van het geheugen niet bij de 'delete' (waar de TS over praat) hoort, dan gaat m'n verhaal niet op.
Echter een delete in C++ roept de destructor van het object aan en de-alloceert dan het geheugen toch, dus dan zou mijn verhaal wel op gaan ( Gaten in de heap )

[.oisyn]

Gaat er nou verder niemand in op de rest van mijn verhaal of is het vandaag negeer-.oisyn-dag

[Robtimus]

bille schreef op 31 maart 2004 @ 20:40:
Als ik mag vragen: in welke situatie zou je willen dat een stuk geheugen NU wordt vrij gemaakt als je helemaal geen zeggenschap hebt over waar een instantie van een object in het geheugen gealloceerd wordt?

Mijn begeleiders willen dat ik mijn afstudeerproject, met real-time, in Java schrijf. Ik gebruik nu jRate (native compiler), waarmee je wel gedeeltelijk geheugenbeheer kan beheersen (ImmortalMemory, ScopedMemory, HeapMemory), maar dat HeapMemory is dus mijn probleem.

En ja, ik zit er zelf ook al over te denken om het maar in C++ te gaan doen. Alleen 1) zij willen Java, 2) ik ben veel beter in Java dan in C++, en 3) met Java kan ik gebruik maken van de javax.realtime package met Scheduler en RealtimeThreads. Geen zin om die zelf te maken op de manier zoals javax.realtime die aanbiedt.

[whoami]

.oisyn schreef op 31 maart 2004 @ 20:25:
[...]

In deze destructor kun je code kwijt die opruimwerk doet. Dit geldt typisch voor lokale objecten op de stack: zodra ze uit scope gaan wordt de destructor aangeroepen, en kun je het opruimwerk gaan doen. Dit betekent bijvoorbeeld het sluiten van een file of netwerkconnectie, of de rollback van een bepaalde operatie als iets fout is gegaan (wanneer er dus een exception wordt gegooid). Dit is code die momenteel niet in de finalize () methode van een object past, omdat je simpelweg niet zeker weet wanneer hij wordt aangeroepen. Met deterministic finalization, en kun je code in de destructor kwijt (en hoef je niet je code vol te peperen met try/finally statements)

Het is een techniek die in C++ heel erg veel gebruikt wordt (hoewel dat ook wel een beetje komt omdat het geen try/finally kent), en hiermee schrijf je bijna op een automatische manier exception-safe code.

Het daadwerkelijk vrijgeven van het geheugen hoeft dus niet per se, dat is helemaal niet het doel van de techniek

Ik weet niet hoe het in Java is, maar in .NET heb je naast een Finalize() (die door de GC wordt aangeroepen, ook de mogelijkheid om een Dispose() method te implementeren, die je zelf aanroept.
In die dispose method kan je een file, netwerk-connectie sluiten, een operatie rollbacken, etc.... Aangezien de programmeur zelf verantwoordelijk is voor het oproepen van die method, weet je ook precies wanneer die method uitgevoerd wordt.
Dispose() geeft enkel het geheugen niet vrij, dat wordt dan door de GC gedaan.

Je hebt dus -ipv bv. delete in C++- dispose aan te roepen:

code:

SomeObject a = new SomeObject();
a.DoSomeStuff();

a.Dispose();

Je kunt dus eigenlijk dit pattern toepassen:

code:

class SomeObject : IDisposable
{

  public SomeObject()
  {
        // constructor
  }

   ~SomeObject()
   {
       // finalizer, wordt door de GC aangeroepen
   }

    public void Dispose()
    {
        Dispose( true );
         // zorg ervoor dat de finalization geen 2x wordt aangeroepen
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose( bool isDisposing )
    {
        if( isDisposing )
        {
             // managed resources vrijgeven
        }

        // unmanaged resources vrijgeven
        // objecten 'nullen'
    }

}

[.oisyn]

Aangezien de programmeur zelf verantwoordelijk is voor het oproepen van die method

Dat is dus niet deterministic finalization, je snapt de strekking van mijn verhaal niet. Het idee ervan is dat het juist automatisch wordt aangeroepen typisch als een object buiten scope gaat. Aangezien een exception helemaal terugspringt naar de exception handler, zijn er ineens enorm veel lokale variabelen in functies die dan buiten scope gaan. En dus is hier geen try/finally statement voor nodig, waar jouw dispose call dan in zou moeten (waardoor het vrij nutteloos wordt om daarvoor dan zo'n methode te ontwerpen, dat is er dan een net als alle andere methoden)

[ Voor 4% gewijzigd door .oisyn op 31-03-2004 22:03 ]