Re: [JAVA3D] Memory problems in J3D App; No Stack Trace Available

[Yazel, David J.]

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