Re: Performance Analysis
- Original Message - From: Rhett Aultman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 19, 2002 5:26 PM Subject: RE: Performance Analysis If you're really concerned about finding the source of the memory drain, I really have to :-) Yyou may want to run the JVM with a JVMPI memory profiling agent running. jProf is a pretty good one. If you do a Google search for jProf, you'll find it, and if you need help using it, I'm here. I've written a JVM profiling agent before, so I know my way around that block. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. -Original Message- From: Holger Prause [mailto:[EMAIL PROTECTED]] Sent: Friday, July 19, 2002 11:17 AM To: [EMAIL PROTECTED] Subject: Performance Analysis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
If you're really concerned about finding the source of the memory drain, I really have to :-) you may want to run the JVM with a JVMPI memory profiling agent running. jProf is a pretty good one. If you do a Google search for jProf, you'll find it, and if you need help using it, I'm here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance Analysis
jProf is actually its own complete memory profiling system. It's based on the JVMPI API, much like my much simpler homebrew profiler was. jProf will give you a pretty detailed analysis of how much of the heap got used up by which types of objects, and IIRC it also gives information on method call sequences that allocated objects and so forth. It's quite expansive, and even comes with an attractive GUI frontend if you don't like looking at reports on the command line. Just do a Google search for jProf -Original Message- From: Holger Prause [mailto:[EMAIL PROTECTED]] Sent: Mon 7/22/2002 10:40 AM To: [EMAIL PROTECTED] Cc: Subject: RE: Performance Analysis If you're really concerned about finding the source of the memory drain, I really have to :-) you may want to run the JVM with a JVMPI memory profiling agent running. jProf is a pretty good one. If you do a Google search for jProf, you'll find it, and if you need help using it, I'm here. I've written a JVM profiling agent before, so I know my way around that block. That very nice, i could need it (Is JProf an api and u coded an profiler using that api?). I have to test it on a custom tag library - performing the xslt transformation. Can u mail the program to me ? My mail is [EMAIL PROTECTED] In the mean time i found out what takes so much memory, its a very brave way of programming (using strings as buffer instead of byte streams, etc...).As workaround i increased the heap of the vm to 256m. IIRC, the heaviest drain on FOP is dealing with graphics and SVG. Thats what all ppl told me as answer for my question what takes most memory.Ill suggest our customer to reduce the use of images. As for the question about keeping a thread with System.gc() running... That may help the JVM to more aggressively clean out memory, but most memory leaks in Java are caused by objects that the GC misses, either because of some unusual memory lay our or (more commonly) because a part of the program is still holding a reference to the object. It may not even be leaking memory...it could just be heavy usage. Heavy but conscientious use of memory would still cause memory to run out, and all the calls to System.gc() in the world won't keep that from happening. Aside from all of that, calling System.gc() does not guarantee that the GC will run. All it does is offer a suggestion that the GC's priority be greater for a short period of time. Ok good to know, but thats not very new for me.Hmm is that Thread running in fop or not ? (I suppos its not because of the funny answers i got) If you really want deterministic garbage collection, there are some JVMPI and JNI tricks that will let you get away with it, but in general, this won't really help your memory concerns. I think that will not be necessary. Thank you very much, Holger -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] winmail.dat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
