jni memory problem

[hagbard23]

Hallo zusammen,
ich habe ein seltsames Problem in unserer java Anwendung. Es handelt sich um eine eclipse rcp anwendung, in der ungefähr 200 mb java objekte allokiert werden, die Referenzen auf unter Umständen über einen Gig native, per jni gewrappte c++ Objekte halten.
Auf den bis jetzt getesteten System läuft alles normal. Auf einem unserer Rechner (8 core , 4 gb ram, xp32) verhält sich das Programm jedoch äußerst seltsam. Es wird zu viel Speicher für die Wrapper Klassen allokiert, bis ca. 1,5 gb. Dann releast das System wieder auf ca. 800 mb , was ungefähr das normale Level ist. Danach alles normal, bis das Programm bei 1,6 gb mit out of mem crasht.

Weis dazu jemand etwas?

 

[Wildcard]

Vielleicht liegt die native Bibliothek auf diesem Rechner in einer anderen Version vor, oder so?

 

[hagbard23]

ne, leider nicht. Ich baue die dll's mit rein. Aberich habe auch überprüft was er anzieht , und das ist schon das richtige. Das völlig mysteriöse ist allerdings, das , wie gesagt, der Speicher bis an die obere Prozessgrenze voll läuft und dann 600 mb releast werden, ohne das der Benutzer was zu tut. Das muß also durch die VM oder die native Bibliothek passieren. Ist allerdings der selbe Build und die selbe VM (1.5.) wie auf einem Rechner, an dem alles normal passiert. Also ich vermute irgenwelche Speicher Abnormitäten durch JNI auf Multicore Rechnern.

 

[Wildcard]

ne, leider nicht. Ich baue die dll's mit rein. Aberich habe auch überprüft was er anzieht , und das ist schon das richtige. Das völlig mysteriöse ist allerdings, das , wie gesagt, der Speicher bis an die obere Prozessgrenze voll läuft und dann 600 mb releast werden, ohne das der Benutzer was zu tut.

Das ist Standard und gewollt.
Der GC räumt nicht (viel) auf solange das System beschäftigt ist. Wenn du jedoch an die oberer Grenze stößt, legt der GC zur Not das ganze System lahm um sofort Speicher freizugegeben. Das ist sozusagen die Notfallstrategie, da die VM abschmieren würde wenn bei Maximalauslastung weiterer Speicher allokiert werden müsste.

 

[hagbard23]

Ja weiß ich schon. Aber das passiert in einem Stress Test, bei dem keine Objekte , die jni referenzen auf jni gewrappte Objekte halten, releast werden. Somit sollte der GC auch gar nichts zum aufräumen haben.

Und wie gesagt, warum verhält es sich auf den anderen Systemen ganz normal. Es wird ja auch viel zu viel allokoiert , um überhaubt so hoch zu kommen. Erst nach dem freigeben ist der Lauf wieder auf einem ähnlichen Level wie auf einem anderen System,.

 

[Wildcard]

Dann wäre doch eine Möglichkeit das der JNI Teil gleich funktioniert und (warum auch immer) du den Speicher mit Plain Old Java Objects zumüllst?
Schonmal einen Heap Dump gezogen? Auch die VisualVM kann bei solchen Diagnosen wunder bewirken.

 

[hagbard23]

hmm...ne kann eigentlich nicht sein, den der heap ist auf 256m eingestellt. Er gibt aber weit mehr frei. Es muss sich also um native Daten handeln. Ja ich habe mir das mal kurz mit JConsole angesehen, aber das gibt wenig aufschluss.
Gibt es eigentlich ein Tool, mit dem man sowohl Java, alsauch native Teile sehen kann?

 

[Wildcard]

Dann kann da aber etwas nicht zusammenpassen. Du sagst die nativen Teile sind stark referenziert und können daher nicht Garbage Collected werden. Genau das passiert aber und sofern der GC selbst keinen wirklich üblen Bug hat (und darauf würde ich jetzt mal nicht wetten) ist eine dieser Aussagen nicht korrekt:
1. der GC gibt Speicher wieder frei
2. der freigegebene Speicher kommt aus den nativen Objekten
3. die nativen Objekte sind stark referenziert und können nich collected werden

 

[hagbard23]

Ich seh ja auch nur Symtome, also sprich ein zu starker Anstieg des Speicherverbrauches im Windows Taskmanager bis ca. 1.5 gig und dann einen Abfall auf 800 mb. Im übrigen werden die Daten selbst nicht freigeben (man sieht sie noch; es sind gerenderte 3D Daten). Was da den Speicher freigibt, weis ich nicht. Soweit ich mich mit der VM auskenne, wird nur selten Speicher an das System releast, auch wenn der Java Heap aufgeräumt, hält die VM den speicher (-> grausiges Verhalten). Das spricht doch gegen die Pojo Theorie.