Have you tried invoking the GC ? - repeatedly and successively ? Though the GC has a mind of its own, I've found that it usually responds if you coax it well enough :).
And about the e-mail link, and based on its findings with the profiler, I can only surmise that there is either a genuine memory leak or there is this issue of (rapid) updates from outside a behavior. May be the support team can tell us if there is indeed a problem. Regards Vaidya >On Wed, 14 Apr 2004 16:09:14 +0200, Eike Tauscher <[EMAIL PROTECTED]> >wrote: >...sounds interesting. I will try it, to get the memory back. Do you >know something about the TransformGroup problem? I have created a basic >class called Object3D sub-classed from TransformGroup. Inside a two >dimensional view, the user can move a point (or more...), by dragging. >The 3D shape of this point is a cube inside Java3D (using my Object3D >class). If the point is moved, I set the translation according to the >new coordinates. I don’t create new Objects but if I do this, the memory >usage increases. If there 10 points moving at the same time (with Text3D >labels)... 20MB and growing. > >I've found some similar inside the forum: > >http://forum.java.sun.com/thread.jsp?forum=21&thread=404881 > >Regards Eike > > > > >-----Ursprüngliche Nachricht----- >Von: Discussion list for Java 3D API >[mailto:[EMAIL PROTECTED] Im Auftrag von N. Vaidya >Gesendet: Mittwoch, 14. April 2004 15:18 >An: [EMAIL PROTECTED] >Betreff: Re: [JAVA3D] AW: [JAVA3D] What happened? > >Hmmm...I think it is something like this. > >Suppose I've a live BranchGroup which is the parent of a subgraph >containing >possibly other Groups and, in particular, Shape3D's with possibly many >Appearances and Geometries. If I detach this BranchGroup then my >experience >has been that the memory corresponding to that BranchGroup and its >subgraph >components will not be released *until* you attach and detach another >BranchGroup. And, of course, when you detach that second BranchGroup >you'll >again see a memory leak corresponding to that second BranchGroup. > >Now, this may not seem like a big problem since the memory is retained >only >between successive BG detaches. However, imagine a situation when apart >from >visualizing the geometry, I'd also be doing other memory allocations as >part >of a computational steering framework, for example, then it does become >a >big issue. The dummy attach/detach seem to be an effective workaround >for my >problem presently. > >I'm not 100% sure that this leak occurs in general with each and every >BranchGroup, or, if it is a function of the various kinds of >capabilities >such as By_ref, U_C_I_O, etc. > >The general advice that I have from Chien, hope that I paraphrase him >correctly and which may or may not be a fix for this particular problem, >is >to perform all BG detaches (and probably attaches too) from within a >behavior especially if the attaches and detaches are very !!!rapid!!!. > > >Vaidya > >=========================================================================== >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". =========================================================================== 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".
