Growing GC Young Gen Times

Jon Masamitsu jon.masamitsu at
Tue Jun 8 19:22:15 UTC 2010


I've file a bug for this.

6959511: KlassHandle leak in runtime



On 06/04/10 14:11, Matt Fowles wrote:
> All~
> Attached is a very small reproduction script.  From the included RE
> 1) set JAVA_HOME
> 2) build with `make`
> 3) run with
> java -verbose:gc -XX:+PrintCommandLineFlags -XX:+PrintGCDetails 
> -XX:+PrintGCTaskTimeStamps -XX:+PrintGCTimeStamps 
> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xms1g -Xmx1g -Xmn10m 
> -Djava.library.path=lib -jar tester.jar 
> 4) notice the growing GC times
> From having experimented with this, the key is the 
> jvm->AttachCurrentThread()/jvm->DetachCurrentThread() calls when 
> combined with the  env->GetObjectClass() and env->GetMethodID() calls.
> If you attach and detatch within the loop, the GC times do not grow 
> without bound.  If you cache the results of GetMethodID outside the 
> loop, the results do not grow without bound.
> Looking at src/share/vm/runtime/handles.cpp:76, you see the comment
> // The thread local handle areas should not get very large
> However, src/share/vm/prims/jni.cpp:1229 allocates a KlassHandle in 
> each call to GetMethodID, which seems to leak as it is never freed 
> from the HandleArea of the thread...
> Obviously, I can fix my code to cache its jmethodID's and/or release 
> threads more often (which I have done and it seems to fix my problem). 
>  But this seems a surprising side effect of GetMethodID()...
> Matt
hotspot-gc-use mailing list
hotspot-gc-use at

More information about the hotspot-gc-dev mailing list