More PrintGCApplicationStoppedTime messages in Java 6
rainer.jung at kippdata.de
Sun Oct 12 03:58:42 PDT 2008
Tony Printezis schrieb:
> Which version of 5 were you using? They could be biased locking
> revocation safepoints. Try running with -XX:-UseBiasedLocking to see if
> they occur. Biased locking is an important and effective optimization in
> most cases and the extra safepoints that it causes are generally benign
> and nothing to worry about.
Great, that's it. When turning of, I don't get the additional stop times
any more. I used Tomcat startup as a simple test case. I understand,
that in general it's not a good idea to turn it off, just wanted to
understand, where they come from.
I used -XX:+TraceBiasedLocking with 1.6.0_07 to further look at those
Count Message type
54 Aligned thread 0xHEX to 0xHEX
265 Total time for which application threads were stopped: NUM seconds
265 Application time: NUM seconds
252 Revoking bias with potentially per-thread safepoint:
70 Revoking bias by walking my own stack:
1 Revoking bias with global safepoint:
323 Revoking bias of object ...
243 Revoked bias of currently-unlocked object
59 Revoked bias of currently-locked object
21 Revoked bias of object biased toward dead thread
4 * Beginning bulk revocation (kind == rebias) ...
3 * Beginning bulk revocation (kind == revoke) ...
7 * Ending bulk revocation
2 (Skipping revocation of object of type ... because it's no longer
2 * Disabling biased locking for type ...
4 Rebiased object toward thread 0xHEX
Of the 265 stop messages, 6 were triggered by Minor GC, the rest belongs
to BiasedLocking (all very short).
Thanks for the explanation!
> Rainer Jung wrote:
>> the number of messages
>> Total time for which application threads were stopped: X.Y seconds
>> produced by PrintGCApplicationStoppedTime increased a lot between Java 5
>> and 6. All of the additional messages refer to extremely short pause
>> times, and none of the prints anything when adding PrintHeadAtGC, so it
>> looks like they are not directly related to actually running a GC task.
>> Can someone give an indication, what other typical reasons for those
>> pauses exist? I tried to track it back from vm/runtime/vmThread.cpp, but
>> wasn't really successful.
More information about the hotspot-gc-use