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

[Krystal Mok]

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...

- Kris

[1]:
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>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.
>>
>>
>>
>>