Chien, Eike's updates are made by user gesture. Wonder if he could be doing that continuously at a rate faster than the FPS to produce a ~20MB leak. The diagnosis for the problem mentioned in his e-mail link does seem to be correct.
Agreed a testcase would help ! Regards Vaidya >On Wed, 14 Apr 2004 11:31:55 -0700, Chien Yang <[EMAIL PROTECTED]> wrote: >Eike, > If you are updating the scene faster than the frame rate, >calling GC mamually will not help. The reason is that j3d has a >memory manager for recycling objects to minmize GC, but this >manager is a little too greedy. Here is the bug report, and it >apply to all scene update operations : > >BugId : 5011160 - setCoordinate memory leak. > >PS: What will you gain from updating the scene faster than the > frame rate ? Java 3D can't be too smart, it has no apps. > knowledge. The apps. developer has to be on the driver > sit. :-) > >- Chien Yang > Java 3D, Sun Microsystems Inc. > > >Eike Tauscher wrote: >> Yes, I've tried to call the GC manually - with no result. >> I've stopped at the moment the Java3D part, because the memory usage is >> too high. Probably I can improve the code, but I will have in the final >> model something like 5000 objects. JOGL has a footprint with same >> objects of 25MB instead of 70MB. I've just tested it. Maybe, I can >> provide some little code example, but therefore I need time. I will try >> to do so tomorrow. >> >> I hope instantly the things will go better for Java3D if it goes to Open >> Source. It wars too long quite about this matter. All people I know >> stopped to go on with Java3D. It works fine, if you have to do only >> little things, but if you want to go deeper inside, it seems to be too >> bugy. >> >> But now is hope! >> >> 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 17:22 >> An: [EMAIL PROTECTED] >> Betreff: Re: [JAVA3D] AW: [JAVA3D] AW: [JAVA3D] What happened? >> >> 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". >> >> =========================================================================== >> 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". =========================================================================== 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".
