Perplexing GC Time Growth

[Jason Vasquez]

I'll try doing more histogram audits on the next run.

We can try serial or parallel GC -- the system will work, but the  
quality of the application will be horrible -- fortunately doesn't  
really matter too much in this environment :)

Thanks
-jason

On Jan 3, 2008, at 13:53 , Y.S.Ramakrishna at Sun.COM wrote:

> Jason Vasquez wrote:
>> One other thing of interest to note, beyond the classloading/ 
>> reflection work, we do quite a bit of JNI interaction as well.  Not  
>> sure how that would affect GC times, but wanted to make sure that  
>> information was in the mix as well.   I have done some cursory  
>> audits of that code, it appears that all heap-allocated objects are  
>> being freed properly from the native side of things, I think we  
>> should be OK in that regard.
>
> You might want to run a jmap -histo audit on a periodic basis (perhaps
> each time a CMS cycle completes) to
> see what might be accumulating in the heap since there is a definite
> growth in the program heap footprint.
>
> It is of course possible that some form of JNI handles are piling
> up and also causing leakage in the Java heap.
>
> The weight of the evidence (the increase in scavenge times, initial
> mark times, remark times and heap usage) seems to point towards an
> increase in the #roots. Let me see if we can get a suitably  
> instrumented
> JVM to you (or at least see if there's existing instrumentation there
> which can be enabled to gather information).
>
> I am also wondering if it might be possible to run with for
> example -XX:+UseSerialGC or -XX:+UseParallelGC to see if the
> same increase in scavenge times is noted. (If it's feasible to
> run with these collectors without badly compromising the fidelity
> of the testing set-up.)
>
> thanks.
> -- ramki

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use