From: N. Vaidya Sent: Wednesday, April, 14th, 2004 20:47 Dear all,
> [Memory leakage in J3D] As I have just spent two bitter weeks searching for and trying to identify this issue a little better, I might be of a little help, there. My application's requirements are that I have a relatively small -about 40 nodes- static scene that is some kind of 'environment' for the content that consists of few hundred up to several thousand (12k) objects to be visualized, resulting in a SG with far more than 50k nodes, TransformGroups, Shape3Ds and ModelClips. The structure is tree-like, recursively generated and consists of home-brewn cone frustra(sp?) extended from geometry.Primitive, contained in a structure of TransformGroups. The content has to be "pluggable" - i.e. exchangeable by user request, as I am developing an application that is able - amongst other things - to visualize neuron morphology data. The visualisazion itself went fine, but when I came across unloading the data from my simple viewing program that I used for testing and playing around with J3D - I had my memory leak out in handy chunks of about 140 to 350 megs. :-) Jip, /megs/. Even with 1G1B RAM this was far too much. As you can imagine, that this was a situation that plainly couldn't persist. Unloading the structures worked in a "visual way". This means that the objects disappeared from screen and I was able to replace the content branch with new content. But all those being loaded 'til that point remained in memory until the viewer was shut down or I ran into the obvious OOME. System.gc and System.runFin were called every now and then (especially after being sure of having created lots of debris) and ironically *all other* objects bacame gc'ed. All, but the SG, I was trying to get rid of. So I started digging *deep* with <http://www.jb2works.com/>'s "Reference Scanner" and found out that the SG stayed cached in J3D's internal structures. I also found the post on this list that suggested destroying the view branch every time after a change has been made. But this ain't helpful, if you're going to code an editor that might be run for several minutes or even a few hours, continuously. I still don't know /what/ finally fixed my leakage, but I strongly suspect that after detaching my content the call to compile() did the trick. The API-Dox say something like "...rebuilds internal caches". Since then, I am able to load, unload, load, unload, ... content as often as my heart desires without having to shut down the view branch even once. And the best is: the heap doesn't grow either. :-) Yiiiehaaaa! Jip, this memory-issue sux big time and was a supreme, royal PITA to get it fixed in my special case. What do I do in my program? * Use a SimpleUniverse * setup the static content branch in a BranchGroup. This part features a "hook" where I am able to attach and detach my dynamic content. Initially this BG is left empty until the user loads something. * add the static part to the scene * add the scene to the universe * compile() all When it comes to removing, I have found the following to work for me: * manually(!) and explicitly destroy *each and every* node in the SG, clean up every field in every instance, set everything null. Yes, this might become more than a little bit annoying. After this is being done, I execute this: [Codesnippet] - simpleUniverse.getLocale().removeBranchGroup(scene) - scene.hookPoint.removeChild(<dynamic content>) - <dynamic content>.detach() - scene.compile() - disposal of the PickCanvas - simpleUniverse.getLocale().addBranchGraph(scene) When it comes to (re-)inserting content, this works fine for me: - scene.hookPoint.addChild(<dynamic content>) - setup PickCanvas OBTW: OS: W32, J2SDK: 1.4.1_01, J3D: 1.3.1, DirectX It might even have helped to upgrade J3D from 1.3 to 1.3.1, as I've found some bug remark addressing removal of nodes. I don't know what of the above is computer voodoo, but I suspect that the almost ridiculous manual removal could be omitted. After having heard and read so many different things regarding this issue ('leave compile() out', 'it's impossible', 'J3D bug', 'broken', 'works for static SG, if you need dynamic SG, use Xith3D or OGL directly', and so on.) and having seen that this is a point almost everyone dealing with J3D comes across, I'm having a little trouble to keep facts from fiction. ;-) Next big thing for me is to get picking to work. For being able to interactively manipulate the morphology this is of course essential. But I'll post a separate message on this. @list maintainer: Big thanks for the subject tags! They're great to help filtering and as a relatively fresh subscriber, I was just about to ask it if would be possible to have them on this list. :-) May I ask for just another little favour - could you please try to fix the tagging so that multiple and repetetive tagging like "Re: AW: [JAVA3D] AW: [JAVA3D] AW: [JAVA3D] What happened?" is more unlikely to happen in future? Or could the posters originating from .de please be so kind to have their software *not* use localized subject tagging? (I'm addressing outlook's and outlook expresses "AW:" standing for "Antwort:" instead of the international "Re:" standing for "Reply:". You even can configure your MUA to use the international tags by default. With respect to the appropriate RFCs (even this might be not too familiar for MS-software), this is strongly recommended.) Another proposal: how about shortening "[JAVA3D]" to "[J3D]" and thus reducing the space eaten up in the subject:-header? Thanks a lot for reading this far, "happy coding!" to all and kind regards, André =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
