Makes perfect sense-I was only using them as a debug tool to monitor GC outside of OptimizeIt (performance slows down so bad using it's profiler it's difficult to test things in a real-time 3D environment).
The main reason for adding the finalize was that Link(s) to SharedGroup objects didn't seem to be gettng GC'd and eventually memory errors would pop up. OptimizeIt would show hundreds of these when there were only 40 currently loaded (I mean in memory, not in the scenegraph), even if an explicit System.gc was called. Since then I've switched from using Links and SharedGroups to using the cloneTree method on a source model, and GC seems much better, but it seems that performance of Links should be better. I've also switched back to the latest J3D 1.2 build. GC under 1.3.1 was not working as expected (witnessed in OptimizeIt), and there seem to be other intermittent errors--in particular, "renderbin" errors, that aren't traceable back to any of my code. Which is too bad, I need the transparency sort order 1.3 offers. But that's another discussion thread. BTW, for those of you looking for J3D in action, I've added several new screenshots to the site at http://vp2.onebigvillage.com/ The project is an open alpha and anyone can download the latest release and check it out. Feedback from this list would be particularly helpful (I'm not just blatantly pimping the project). Scott ----- Original Message ----- From: "Daniel Selman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 11, 2002 10:08 AM Subject: Re: [JAVA3D] Memory problems in J3D App; No Stack Trace Available > Pasi, > > You are quite correct. > > Finalizers are evil - and should almost always be avoided. Implementations > vary, but the SUN VM runs a separate finalizer thread and registers the > objects that have finalizers on that thread, so the finalizers can be run at > GC time. It is also possible to break GC by creating a new object reference > inside your finalizer - essentially creating a perpetually reachable object. > > You should really, really know what you are doing if you write a finalizer. > They are not C++ destructors. > > Sincerely, > > Daniel Selman > > Author - "Java 3D Programming" > http://www.manning.com/selman > > -----Original Message----- > From: Discussion list for Java 3D API > [mailto:[EMAIL PROTECTED]]On Behalf Of Pasi Paasiala > Sent: Wednesday, April 10, 2002 11:33 PM > To: [EMAIL PROTECTED] > Subject: Re: Memory problems in J3D App; No Stack Trace Available > > > You said that you have finalize methods in your major classes. Do you have > plenty of instances of these classes? I used to have the finalize methods > also, but learned that taking them out reduced my memory consumption a lot. > In the book "Java Platform Performance" by Steve Willson, it is written: > > "The only thing that can be said for certain is that adding a finalizer will > extend the lifetime of an object." and "Using a finalizer can also leave > behind critical resources that won't be discovered for an indeterminate > amount of time." > > That book contains also other hints that you might find usefull. > > Pasi > -----Original Message----- > From: Discussion list for Java 3D API > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Mobile > Sent: 11. huhtikuuta 2002 3:22 > To: [EMAIL PROTECTED] > Subject: Re: [JAVA3D] Memory problems in J3D App; No Stack Trace Available > > > Still digging into the source of the outofmemoryerrors, but since I > increased the heap to 128 it happens less frequently. But what happens if > you specify a 128MB heap size on a machine with less than 128MB? (Realizing > that's not neccessarily a question for this group). > > Using a manual /gc command to the game's chat/command line (I assume that's > what you meant David) sometimes releases one-two MB of meory. Garbage > collection on my classes does happen automatically, I see the output from my > finalize methods. > > While I continue to dig through this, I wanted to point out that we normally > run about 60-90MB of usage according to taskmgr. But when we minimize the > window and restore it, memory drops down to under 30MB or so (give or take a > few MB) and slowly builds up from there. I have finalize methods on all of > the major classes, and they're not what's being freed up. THEN, (and here's > the wierd part),when I do a gc manually from the app, memory goes back UP to > 60+MB. > > Very strange... > > > Scott > ----- Original Message ----- > From: Yazel, David J. > To: [EMAIL PROTECTED] > Sent: Wednesday, April 10, 2002 1:12 PM > Subject: Re: [JAVA3D] Memory problems in J3D App; No Stack Trace Available > > > Thats very wierd... I know it is not helpful, but this does not happen to > us. I have had our client running for days in test mode where avatars run > from one end of the world and back again to test this sort of thing. Our > memory usage typically runs at 55mb to 90mb and sometimes a bit higher, so > we usually run with a max heap of 120mb. Having no stack trace on your > crash is a bit weird. There is only one condition I have ever seen that > causes this... and that is allocating an array more than the size of the > memory you have. Try adding a /gc command from the command line so you can > manually trigger GC. If you see your memory not reducing after doing a few > GC's in a row, then you probably have a leak, regardless of what OptimizeIt > is saying. I would first try to figure out which thread is crashing, since > that would narrow it down. Double check all your assumptions regarding your > memory usage to make sure you don't have an obvious leak somewhere.. like > caching textures, etc. The next thing to think about is a possible driver > issue... sometimes Java3d craps out if the driver it is talking to comes > back with an unexpected response. > > Wish I could be of more help. > > Dave Yazel > > > -----Original Message----- > From: Scott Mobile [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 10, 2002 2:01 PM > To: [EMAIL PROTECTED] > Subject: [JAVA3D] Memory problems in J3D App; No Stack Trace Available > > > Before anyone suggests I browse the archives, don't bother--I have, but > haven't found a solution or even direction to look. > > I'm having serious problems with java.lang.OutOfMemory errors that have "no > stack trace" in my little MMORPG aspp. They're random, sometimes coming > after the app's been running for an hour, sometimes after a few minutes. > > I've been very careful about creating objects only when needed. > > I've tired bigger nitial and max heap sizes. > > I've compiled with full debug info (still no strack trace info shows up). > > I've ran OptimizeIt!'s profiler, and see objects building up and being > freed, but very slowly--at times there are hundreds of my "Scenery" class > objects that have been detached(), null'd and are ready for GC, but they > don't get cleaned out. The scenery class itself uses little memory, but > the models they load (using cloneTree from a source model object), will of > course use up some memory. > > I tried using SharedGroups and Links, but they were even worse at being > freed, and would build up into the hundreds, and then out of memory errors > would happen. > > I've reduced J3DThreadPriority to 8 (any less than that and the app becomes > poorly responsive), to make sure the rendering threads weren't keeping the > GC low-priority thread from running. > > In memory, at any given time, I might have 10 terrain textures (256x256 > JPG's), 81 terrain "blocks" (a 4x4 poly textured mesh), and anywhere from > 30-100 "Scenery" objects, which are loaded from the StarFire 3DS loader, and > have their own textures (which have been optimized for size and dimensions). > The terrain blocks and Scenery objects are loaded dyanimcally as the moves > around the world. Model and terrain height data is received form the server > (eventually to be stored locally), and processed in the FrameManagement > behavior below. > > The FrameManagement behavior handles animation, player movement, model > loading, dropping out of range terrain and scenery objects, requesting new > ones from the server, etc. The processStimulus typically runs in under > 20ms. > > There's also another thread handling socket communications to and from the > game server. For now these communications are TCP based, but I'll probably > move a few non-essential functions to UDP (player movement, time of day > synchonization, chat messages, emotes, etc). These messages usually > continue to be received and to be sent after the out of memory error; when > that happens, only the rendering seems to stop. > > I've tried incremental garbage collection. Of course, forcing a System.gc() > isn't an option, it causes serious stutters in the display. > > I realize this isn't much to go on, but I'm sure somebody (David Y.?) has > run into these problems before--effective GC when the system is going full > bore rendering highest possible framerates. It seems the bigger the app > gets, the worse the out of memory errors occur, to the point that I'm afraid > of adding any more features to it... > > Any input/direction would be helpful.. > > Scott > Virtopia 2 3D Project > http://vp2.onebigvillage.com > > =========================================================================== > 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".
