branchgroups killen, speicherplatz freigeben

[Mr.White]

wir machen ein java 3d projekt an der uni:

eine spielhalle (branchgroup) mit pickbaren-automaten. beim picken werden module (einzeln) aufgerufen und als branchgroups einzel an die haupt-branchgroup gehaengt, die spielhalle wird abgehaengt. wenn ich zurueck zur spielhalle gehen will, moechte ich gerne dass die abgehaengten modul-branchgroups detacht und vollstaendig aus dem speicher entfernt werden.

da sie verschiede behaviors enthalten kann ich sie von dem garbage collector nich einfach beseitigen lassen, z.b "null" der moudul-bg uebergeben und vom garbage collector aufsammeln lassen (behaviors setzen angeblich eigene referenzen, so dass sie die loeschung der gesammten branchgroup verhindern).

hat jemand ne idee,

thx

 

[DP]

hier mal lesen (kurz): http://java.sun.com/developer/JDCTechTips/2004/tt0122.html#2

dann den hier machen: http://java.sun.com/developer/JDCTechTips/2003/tt0408.html#1

sollte helfen.

cu

 

[Mr.White]

danke erstmal fuer die antwort, aber mein problem ist mehr 3d-bezogen. es ist mir klar wie garbage collector arbeitet, aber wie gesagt den pointer der branchgroup auf null setzen und dann garbage c anschmeissen

System.runFinalization();
System.gc();

hilft da auch wenig, weil die behaviors nicht erlauben dass die branchgroup aus dem speicher geworfen wird

ich haenge zb ein modul (wie gesagt: eine eigenstaendige branchgroup) ab und die spielhalle dran, doch das behavior des moduls ist immer noch drin (steuerkreuztasten) und die berechnungen und ausgaben des mouduls sind aktiv obwohl die sichtbaren elemente alle verschwunden sind und das aeussere der spielhalle (und alle ihre funktionen) korrekt dargestellt werden.

das hauptproblem bleibt jedoch speicherplatz, denn nach mehrmaligem starten eines moduls kommt irgendwann (abhaengign von der speicheranforderung des jeweiligen moduls) die meldung out of memory. das sagt mir dass die alten instanzen desselben moduls nicht aus dem speicher entfernt werden obwohl der bentuzte pointer die selbe bezeichnung hat. annoying :evil:

 

[Oxygenic]

Die Links waren wirklich extrem an der Sache vorbei...

So weit ich weiß, leckt der Speicher gerade bei der Geschichte ein wenig, aber das ist ein bekanntes Problem. Ich bin dazu übergegangen, den SceneGraph unterhalb einer BranchGroup manuell zu zerlegen, d.h. die Elemente dort rekursiv zu untersuchen und zu entfernen (bei Shape3Ds die Geometry entfernen, Groups alle Childs nehmen etc.).

Bei Interesse kann ich die Methode gerne mal posten, ansonsten wird sie in der Klasse com.vwp.j3d.loaders.DataCache der kommenden Version der Java XTools zu finden sein.

 

[Mr.White]

poste bitte die methode, wuerde sie mir gerne angucken. momentan bastel ich an den locals rum, sollen ja beim freigeben von resourcen hilfe leisten.

thx und cu

whity

 

[Mr.White]

ich fuerchte, ich muss aufs applet-killen und -erschaffen ausweichen, denn die removeLoacale(Locale) bzw. removeAllLocales hilft bei oben beschriebenen speicherproblemen auch nicht

 

[dergrüne]

Gibt es zu dem Problem eigentlich aktuell ne Lösung in Java 3d?

Benutze Version 1.5.1 und habe das selbe Problem, dass wenn ich die BranchGroup remove und auf dem simpleU ein cleanup() mache und danach sogar alle referenzen auf null setze und den gc anstoße, trotzdem noch alles im Speicher ist. Und beim erneuten Aufbau des Scenegraphen einen out.of.memory bekomme.

mfg