Are there any liveness issues about thread scheduling in the JVM? (original) (raw)

Krystal Mok rednaxelafx at gmail.com
Sun Jul 15 19:20:22 PDT 2012

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

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

More information about the hotspot-dev mailing list