Growing GC Young Gen Times
jon.masamitsu at oracle.com
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:
> 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()...
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev