Safepointing & Locking issue

[Nicolas Michael]

Hi Dave,

Am 08.07.2010 16:59, schrieb Dave Dice:
>> These are all the _sync_* that I get:
>>
>> sun.rt._sync_ContendedLockAttempts = 1625
>> sun.rt._sync_Deflations = 66821
>> sun.rt._sync_EmptyNotifications = 0
>> sun.rt._sync_FailedSpins = 0
>> sun.rt._sync_FutileWakeups = 56
>> sun.rt._sync_Inflations = 66870
>> sun.rt._sync_MonExtant = 6784
>> sun.rt._sync_MonInCirculation = 0
>> sun.rt._sync_MonScavenged = 0
>> sun.rt._sync_Notifications = 116109
>> sun.rt._sync_Parks = 117295
>> sun.rt._sync_PrivateA = 0
>> sun.rt._sync_PrivateB = 0
>> sun.rt._sync_SlowEnter = 0
>> sun.rt._sync_SlowExit = 0
>> sun.rt._sync_SlowNotify = 0
>> sun.rt._sync_SlowNotifyAll = 0
>> sun.rt._sync_SuccessfulSpins = 0
>
> You've only got 6784 extant monitors, which is quite reasonable.   (We over-provision somewhat to allow per-thread free lists of readily usable monitors -- this reduces contention on the central free list -- so the actually number of monitors in-use at any one time will have been much less than 6874).    The monitor scan/scavenge costs should be dominated by and only a small fraction of the overhead to rendezvous for the safepoint.   At the last safepoint you had 49 monitors actually in-use, which probably means you had about 49 threads blocked on wait() or contended monitor entry.   Does that agree with what you know of the application?   The inflation and deflation counts relative to the # of extant monitors suggests that monitors are circulating properly.   So I don't see anything particular amiss in the data above.

49 threads sounds very reasonable. There are different types of threads, 
but the ones that are doing wait() on the one queue are 50 threads in total.

>> Thanks for pointing me to synchronizer.cpp, this sounds worth reading your
>> comments there!
>
> By all means feel free to ask questions.

Great, thanks.

Nick.