Are there any liveness issues about thread scheduling in the JVM?
david.holmes at oracle.com
Sun Jul 15 19:54:42 PDT 2012
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" .
> 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.
> - Kris
> On Mon, Jul 16, 2012 at 8:55 AM, David Holmes <david.holmes at oracle.com
> <mailto: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
> 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
> 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
> Thanks a lot for your time.
More information about the hotspot-dev