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]


Reply via email to