Perplexing GC Time Growth
jason at mugfu.com
Thu Jan 3 13:44:35 PST 2008
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 :)
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
> 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.)
> -- ramki
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev