Safepointing & Locking issue

[Nicolas Michael]

Thanks, I will add -XX:+TraceSafepointCleanupTime as well. The output 
for -XX:+PrintSafepointStatistics was in my previous mail -- it's 
basically "DeoptimizeFrame" about 1200 times a second.

And Ramki, you are right: It's actually more about the frequency of the 
safepoints, not necessarily their duration. I didn't do a real (i.e. 
SunStudio) profiling, just some quick DTrace profiling, which always 
captured deflate_idle_monitors() being top of the stack.

Nick.

Am 08.07.2010 19:03, schrieb Y. S. Ramakrishna:
>
>
> On 07/08/10 08:06, Karen Kinnear wrote:
>> Nicolas,
>>
>> It would also be very helpful if you could possibly gather information
>> to determine
>> why you are running so many safepoints.
>>
>> Could you possibly try running with the following flags on a fairly
>> current jdk7 binary?
>> -XX:+PrintSafepointStatistics -XX:+TraceSafepointCleanupTime
>>
>> That should tell you why you are running so many safepoints (which
>> would not be caused
>> by lock inflation/deflation). It will also tell you details of time
>> spent in different components
>> of the safepoint cleanup time, including lock deflation. Note that the
>> flags require a development
>> build, like fastdebug.
>
> The two you mention above are also available in product builds, thanks
> to Xiaobin.
> But probably moot now considering what Nicolas has figured out since the
> first email on this thread (i.e. frequency of safepoints, not their
> duration or deflation per se, being the cause of his overhead).
>
> -- ramki
>
>