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".
