Are there any liveness issues about thread scheduling in the JVM?

Xie Xiaodong xxd82329 at gmail.com
Mon Jul 16 05:34:30 PDT 2012


Hello, David and Krystal,


I've seen your discussion in
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004106.html,
thanks a lot for your attention.

Unfortunately, this issue cannot be reproduced easily. And I've seen such
scenarios twice, both were in production environment, when the lock was
heavily contended.

BR,
Xiaodong Xie


On Mon, Jul 16, 2012 at 4:54 AM, David Holmes <david.holmes at oracle.com>wrote:

> On 16/07/2012 12:20 PM, Krystal Mok wrote:
>
>> This is actually the source of my earlier mail "Multiple Java threads
>> seem to have locked the same object monitor from the thread dumps" [1].
>> Apparently Xiaodong didn't subscribe to the mailing list before sending
>> his mail to hotspot-dev, and while waiting for moderator approval he
>> sent another mail directly to me...
>>
>
> I didn't see any mention in here of the same object claiming to be locked,
> so I didn't connect them.
>
> David
> -----
>
>  - Kris
>>
>> [1]:
>> http://mail.openjdk.java.net/**pipermail/hotspot-runtime-dev/**
>> 2012-July/004106.html<http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004106.html>
>>
>> On Mon, Jul 16, 2012 at 8:55 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>> wrote:
>>
>>     On 10/07/2012 9:20 PM, Xie Xiaodong wrote:
>>
>>
>>         We are facing some interesting behavior in production.
>>
>>     <snip>
>>
>>         Here are some thread dumps taken at different time. During this
>>         period,
>>         only httpSSLWorkerThread-10080-99 can make progress. Other
>>         threads were
>>         always stuck in the synchronization point. And "waiting to lock
>>         <0x75b395d8>", this hex number changed several times. What does
>>         this number
>>         mean?
>>
>>
>>     An example:
>>
>>     - waiting to lock <0x75b395d8> (a casinomodule.util.__**TimeUtilImpl)
>>
>>
>>     The number is the address of an object that the threads are trying
>>     to lock. It is an instance of casinomodule.util.__**TimeUtilImpl. If
>>
>>     the address, for a given thread, keeps changing, it means that the
>>     threads are in fact making progress, as they must have locked object
>>     form the previous stack dump and then moved on to the current one.
>>     If the number is different for different threads then they are
>>     simply trying to lock different objects.
>>
>>     There would appears to be a synchronization bottleneck in this
>>     "casinomodule"
>>
>>     David
>>     -----
>>
>>
>>         Thanks a lot for your time.
>>
>>
>>
>>
>>


-- 
Sincerely yours and Best Regards,
Xie Xiaodong


More information about the hotspot-dev mailing list