[Fwd: Deadlocked Thread State is RUNNABLE?]

[David Holmes - Sun Microsystems]

Dmytro Sheyko said the following on 11/24/09 19:42:
> What is the reason to hold lock on class being initialized while 
> initializing its superclasses?

The lock of the class is not held during its own or its superclass's 
initialization. A lock is only used to set the current class as 
being-initialized, and for concurrent initialization attempts to be able 
to wait.

David Holmes

> Wouldn't it better acquire lock after superclass initialization just 
> before calling static initializer?
> This would prevents some kind of deadlocks.
> 
> Thanks,
> Dmytro
> 
>  > Date: Wed, 18 Nov 2009 11:58:18 +1000
>  > From: David.Holmes at Sun.COM
>  > Subject: Re: [Fwd: Deadlocked Thread State is RUNNABLE?]
>  > To: Mandy.Chung at Sun.COM
>  > CC: serviceability-dev at openjdk.java.net; 
> hotspot-runtime-dev at openjdk.java.net
>  >
>  > Mandy Chung said the following on 11/18/09 11:36:
>  > > It's a known bug:
>  > >
>  > > 6501158: Thread state is incorrect during class initialization
>  > > procedure
>  > >
>  > > I recalled the discussion for this bug but don't remember if we
>  > > discussed enhancing the java.lang.management spec to cover "waiting"
>  > > on VM internal actions.
>  > >
>  > > David will probably have more information about this.
>  >
>  > I have nothing really to add save what is stated in the CR, but as my
>  > main comment was not public I've moved it to being public (and dropped
>  > myself as RE) and reproduce it below.
>  >
>  > Quite simply the code that does the "wait" is low-level in the VM and
>  > does not come through the normal Object.wait() path that would set the
>  > Thread.State. It can be "fixed" but there are a couple of additional
>  > issues that also need to be addressed due to the fact that the monitor
>  > used is not associated with Java-level object. (The JLS was updated in
>  > this regard.)
>  >
>  > The meta-discussion was whether we should introduce a new Thread.State
>  > to cover this special case (waiting for class initialization), and that
>  > discussion seemed to lean towards doing this (I suggested it and Mandy
>  > agreed it seemed like a good idea :) ) But things did not progress from
>  > there.
>  >
>  > Cheers,
>  > David
>  > -----
>  >
>  > >From 6501158:
>  >
>  > The submitter quotes the JLS with regard to the class initialization
>  > procedure and how synchronization is employed. In fact hotspot does not
>  > synchronize using the Class object monitor during class initialization -
>  > this is to avoid denial-of-service style attacks just by explicitly
>  > locking a Class object. The JLS is in the process of being updated to
>  > say that a "unique initialization lock " is used for class
>  > initialization, not necessarily the Class object's lock. This brings the
>  > spec into line with the hotspot implementation.
>  >
>  > The reason I mention this is that the monitor that hotspot uses is
>  > associated with the klassOop for the class. The monitor code sets
>  > current_waiting_monitor() or current_pending_monitor() as appropriate
>  > during wait() or monitor entry. The management code, via the
>  > ThreadService::ThreadSnapShot gets a hold of the object associated with
>  > the monitor for a blocked thread and assumes that the object is in fact
>  > the oop for a java.lang.Object. When the klassOop is treated as in
>  > instance oop and queried for its own class etc then we end up crashing
>  > the VM.
>  >
>  > The suggested fix correctly sets the thread state to "WAITING":
>  >
>  > Full thread dump Java HotSpot(TM) Tiered VM
>  > (1.7.0-internal-dh198349-fastdebug mixed mode):
>  >
>  > "Runner" prio=3 tid=0x08171800 nid=0xb in Object.wait()
>  > [0xcb99d000..0xcb99dbb0]
>  > java.lang.Thread.State: WAITING (on object monitor)
>  >
>  > but additional changes are need in ThreadSnapShot to discard the
>  > non-instance oop. (It seems JvmtiEnvBase::get_current_contended_monitor
>  > would need a similar modification). This seems to work and getThreadInfo
>  > simply reports eg:
>  >
>  > Current thread info: "Runner" Id=8 WAITING
>  >
>  > which seems okay. And getLockInfo() returns null.
>  >
>  > It is unclear however whether reporting this information actually
>  > violates the specification for these management API's. A thread is only
>  > WAITING when performing Object.wait(), in which case there must be an
>  > Object being waited upon and so LockInfo must return non-null
>  > information. Yet that is not the case here.
>  >
>  > It seems to me that while we can report the information above, it might
>  > be better to see whether the management specification can be enhanced to
>  > cover "waiting" on VM internal actions and to then report this
>  > circumstance as one of those.
>  >
>  > Note also that the existing hotspot code could already be susceptible to
>  > a crash due to the use of the klassOop monitor for class initialization.
>  > If the timing were just right, a call to getThreadInfo could see a
>  > thread blocked trying to acquire this monitor (not wait upon it) and
>  > that would be captured by the ThreadSnapshot and eventually cause a
>  > crash. The fact that the snapshot requires a safepoint makes it less
>  > likely that you would encounter the target thread while blocked on the
>  > monitor, as the monitor is only held for a short period during class
>  > initialization.
>  >
>  > I will await discussion with the management/monitoring folk before
>  > deciding how best to proceed with this CR.
>  >
> 
> ------------------------------------------------------------------------
> Windows Live: Keep your friends up to date with what you do online. 
> <http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010>