[Java] Geheugenmanagement

[flowerp]

Modbreak:

Dit topic is afgesplitst van [rml][ alg] slechtste prog voorbeelden.[/rml].

HIGHGuY schreef op vrijdag 09 december 2005 @ 23:53:
(weet echter niet hoeveel .NET hier ook effectief van consumeert... blijkbaar neemt Java genoegen met 512MB max of zo ?)

Java kan standaard niet meer dan 64MB geheugen aan. Deze harde limiet zit er al sinds de oer-tijden van Java in. Kennelijk zijn ze bij Sun vergeten dat mensen tegenwoordig meer RAM in hun computer hebben. Je kunt het wel met een switch (-Xmx bij Sun VM) verhogen op de commandline, maar niet iedereen die een Java programma wil runnen snapt dat en zelfs als ze het snappen vergeten ze het vaak om weten ze niet wat precies de verhoogde limiet moet zijn.

Nog erger is dat de genoemde switch eigenlijk VM implementatie specificiek is. Hoewel de meeste (alle?) VM bouwers hem overnemen, staat ie niet in de Java spec. (alle switches die met een X beginnen zijn implementation dependend).

Als jij dus een app bouwt die universeel op elk platform moet draaien en die app gebruikt meer dan 64MB dan heb je als distributeut gewoon een probleem met Java.

Dit is een beetje een WTF! van de Sun designers.

[ Voor 5% gewijzigd door NMe op 04-01-2006 16:51 ]

[Macros]

Ik ben het totaal niet eens met flowerp. Teneerste geeft hij duidelijk aan dat het geen harde limiet is maar een softlimiet. En je kan wel de hoeveelheid geheugen aanpassen in een Java applicatie als programmeur zodat de gebruiker niks van command switches hoeft te weten dmv. je manifest in je jar file.

[flowerp]

Macros schreef op zaterdag 10 december 2005 @ 15:35:
Ik ben het totaal niet eens met flowerp. Teneerste geeft hij duidelijk aan dat het geen harde limiet is maar een softlimiet.

hmppfff...

En je kan wel de hoeveelheid geheugen aanpassen in een Java applicatie als programmeur zodat de gebruiker niks van command switches hoeft te weten dmv. je manifest in je jar file.

Dat van die manifest wist ik niet en zal ik eens nakijken wat daar precies mee kan. Ik vraag me dan wel af of dit mechanisme altijd werkt. Niet elke java app komt als een jar. Eclipse bijvoorbeeld niet, en daar moet je heel expliciet je max. geheugen opgeven (is voor Eclipse publiek natuurlijk niet zo bijster moeilijk, maar toch)

[Macros]

Eclipse levert een launcher die een ini file gebruikt om de hoeveelheid geheugen te bepalen. Maar dat heb ik nog nooit hoeven doen. Op 1 uitzondering na omdat ik een file van meer dan een 800.000 lines wilde openen.
Het mooie van de limieten is dat een Java app bijna nooit je hele systeem overneemt kwa geheugen. Helaas kan je dat niet voor de cpu specificeren, maar wel met het geheugen. Het geeft je ook veel kracht voor bepaalde apps. Als een programma meestal maar weinig ram nodig heeft geef je het heel weinig in het begin maar met een normale max. Weet je dat het altijd veel gebruikt dan geef je het meteen een sloot geheugen.

Java springt niet zo efficient met het geheugen om, dus het is handig dat je dat soort dingen kan bepalen. Bij C programma's is het veel lastiger om dit te doen, die kan dus door een geheugen lek je hele ram vol laten lopen.

[flowerp]

Macros schreef op zaterdag 10 december 2005 @ 21:39:
Eclipse levert een launcher die een ini file gebruikt om de hoeveelheid geheugen te bepalen. Maar dat heb ik nog nooit hoeven doen. Op 1 uitzondering na omdat ik een file van meer dan een 800.000 lines wilde openen.

Als je enterprise development doet met bv de MyEclipse feature dan wordt standaard -Xmx512mb aangeraden. (op de meeste systemen gebruik je -vmargs, alleen op de Mac gebruik je een bestand in je bundle).

Als een programma meestal maar weinig ram nodig heeft geef je het heel weinig in het begin maar met een normale max. Weet je dat het altijd veel gebruikt dan geef je het meteen een sloot geheugen.

Bij Apple had je dat vroeger ook ( alle OS'en < OS X), en dat mechanisme goldt voor alle applicaties, of ze nu C, C++, Java, Pascal or whatever waren. Ik kan je vertellen dat zelfs de meest die-hard Mac aanhangers dat mechanisme haatte. Mischien onterrecht, als je de geheugen limiet zo makkelijk kunt aanpassen in het manifest, maar het geheugen management voor op die client wordt toch wel als 1 van de dingen genoemd waarom Java het zo slecht doet op de desktop. In veel situaties WIL je helemaal geen max, maar gewoon zoveel als je app run-time nodig heeft (en dit kan per situatie dus heel verschillend zijn).

Java springt niet zo efficient met het geheugen om, dus het is handig dat je dat soort dingen kan bepalen.

Net zoals dat het Mac OS geen echte paging had, is het dus in Java geen feature maar een lapmiddel om een heel slecht geimplementeerd onderdeel nog enigzins werkbaar te maken.

[ Voor 4% gewijzigd door flowerp op 10-12-2005 22:43 ]

[Macros]

Net zoals dat het Mac OS geen echte paging had, is het dus in Java geen feature maar een lapmiddel om een heel slecht geimplementeerd onderdeel nog enigzins werkbaar te maken.

Dat vind ik niet. Als je wilt kun je al je java apps 4gig geven. Je wilt juist niet dat je app zoveel gebruikt als ie nodig heeft. Want in veel OS'en heb je ook nog tig gig aan swap file en het duurt zeker een hele poos voordat je een out of memory exception krijgt.

Het geheugen is niet de reden waarom Java het niet zo goed doet op de desktop. Ik denk dat het meer een combinatie van vele kleine dingetjes is.

[flowerp]

Macros schreef op zaterdag 10 december 2005 @ 22:48:
[...]

Dat vind ik niet. Als je wilt kun je al je java apps 4gig geven.

Nou, 2GB op de x86-32 en Apple 32-bit VMs, 4GB op de SUN 32-bit sparc VM en veel meer dan dat op 1 van de 64-bits VMs als ik me niet vergis. Dat is dus het probleem niet. Het probleem is dat je dat geheugen eigenlijk niet meer terug krijgt als het eenmaal een keer gealloceerd is. Heeft je app bij het opstarten even 256MB nodig en daarna nog slechts 32MB, dan zal je app toch z'n hele lifetime op 256MB blijven. Ik geloof dat deze situatie in Mustang iets aangepast gaat worden.

Je wilt juist niet dat je app zoveel gebruikt als ie nodig heeft.

Of je het nu eigenlijk wilt of niet, het feit is dat 'gewone' desktop apps het wel kunnen zonder dat het problemen opleverd en Java desktop apps dus niet. Dit is gewoon een beperking die op de desktop niet handig is. Server-side draai je meestal maar 1 appserver die gewoon een bepaald gedeelte van het geheugen helemaal mag gebruiken, maar op de desktop heb je heel erg veel applicaties die netjes met elkaar moeten samenwerken.

Want in veel OS'en heb je ook nog tig gig aan swap file en het duurt zeker een hele poos voordat je een out of memory exception krijgt.

Delete operator in Java? Feitelijk een commando aan de GC -> "collect nu en doe het dan ook echt NU voor dit specificeke object". In java heb je wel een commando om de GC te starten, maar dat is meer de vraag: "zou je zodra je er zin in hebt mischien binnenkort willen collecten voor alle objecten".

Het geheugen is niet de reden waarom Java het niet zo goed doet op de desktop. Ik denk dat het meer een combinatie van vele kleine dingetjes is.

Niet -de- reden, maar wel degelijke 1 van die vele kleine dingetjes. Een andere major issue is het opstarten van apps en het laten zien van de apps in process lists, task selectors, task bars, etc. Daarbij hoort overigens ook weer het laten zien van het geheugen verbruik bij (voor advanced users), wat onder geen enkel OS betrouwbare waarden laat zien.

[ Voor 6% gewijzigd door flowerp op 11-12-2005 09:32 ]

[Macros]

Mustang gaat veel verbeteren op veel gebieden. Maar 1 misverstand is dat als een programma geheugen freed dat het dan terug naar het OS gaat. Bij meeste OS'en en talen gebeurd dit niet. Als dat in Windows wel gebeurd dan zie ik niet waarom het met Java niet zou werken.
Ik gebruik twee Java desktop applicaties en heb nooit problemen met geheugen. Eclipse en Azureus.

[flowerp]

Macros schreef op zondag 11 december 2005 @ 15:48:
Mustang gaat veel verbeteren op veel gebieden. Maar 1 misverstand is dat als een programma geheugen freed dat het dan terug naar het OS gaat.

Iniedergeval zou in Mustang het feitelijke geheugen dat de JVM gebruikt meer overeen moeten komen met het opgegeven geheugen door het OS. Zie oa Xiaobin's blog over dit onderwerp: http://weblogs.java.net/b...08/perception_real_1.html

Bij meeste OS'en en talen gebeurd dit niet.

Wel waar. Ik schreef bijvoorbeeld een tijd terug een C++ app op een Windows machine met MFC. Een van de dingen die de app deed was een log bijhouden (in memory). Die log kon nogal groot worden (120MB was niets), zodat ik er een clear-log functie bij had gemaakt. De code achter de clear-log liep een hele lijst af en riep overal een (cascading) delete op aan. Nadat de functie werd aangeroepen nam een paar seconden later het geheugen gebruik zoals geraporteerd door de taskmanager enorm af.

Als dat in Windows wel gebeurd dan zie ik niet waarom het met Java niet zou werken.

Ik werk voornamelijk met Mac OS X en Linux, maar heb dus wel eens Windows gebruikt. Onder alle Operating Systemen werkt het zo.

Ik gebruik twee Java desktop applicaties en heb nooit problemen met geheugen. Eclipse en Azureus.

Check onder Linux maar eens wat Eclipse zogenaamd verbruikt. Dan schrik je wel even. Overigens is het niet alleen Java hoor, Netscape geeft ook altijd onmogelijk hoog geheugen vebruik aan (Debian Linux 2.6 kernel).

[Macros]

Mijn Eclipse met ongeveer 5000 source files gebruikt tussen de 500 en 600 megabyte, valt dus wel mee.

[flowerp]

Macros schreef op maandag 12 december 2005 @ 00:16:
Mijn Eclipse met ongeveer 5000 source files gebruikt tussen de 500 en 600 megabyte, valt dus wel mee.

Maar je hebt toch niet al die 5000 files in je working set??? (dwz, in je open files working set)

Is wel meer geheugen dan de standaard 64MB, dus je hebt parameters moeten veranderen. Is ook sterk afhankelijk van je plug-ins die je geladen hebt.

Met MyEclipse heb je in het MyEclipse menu een run garbage collection item die je wat meer gedetaileerd laat zien wat Eclise vebruikt. Met een klein projectje open zit ik op 253MB Max, 69MB allocated, 37MB used. In de Mac OS X Activity display staat Eclipse 2x keer (waarschijnlijk loader en echte process apart). Het echte process staat op 137MB true memory en 640MB virtual memory. Echt duidelijk is dit niet...