synchronization of JVMTI phase notifications [Fwd: Data visibility between threads in Hotspot]

[Daniel D. Daugherty]

I'll chime in on parts of this thread below.



Tim Bell wrote:
> I don't know the precise answer to this question, so I am forwarding 
> it to the Serviceability list to get a wider audience.
>
> -------- Original Message --------
> Subject:     Data visibility between threads in Hotspot
> Date:     Tue, 10 Feb 2009 11:14:24 -0800
>
> Hi Tim,
>
> I have a Hotspot question. Chuck Rasbold pointed me to you. Feel free to
> forward this message to other experts at Sun, if needed.
>
> If one Hotspot engineer wants to guarantee the immediate visibility of a
> write to a static variable to reads in other threads (assuming the reads
> and the writes are properly synchronized via a mutex), what does s/he do?
>
> Does the use of MutexLocker guarantee the visibility? It probably does 
> not.

I believe that MutexLocker does guarantee the visibility:

src/share/vm/runtime/mutexLocker.hpp:

   133  // See orderAccess.hpp.  We assume throughout the VM that 
MutexLocker's
   134  // and friends constructors do a fence, a lock and an acquire 
*in that
   135  // order*.  And that their destructors do a release and unlock, 
in *that*
   136  // order.  If their implementations change such that these 
assumptions
   137  // are violated, a whole lot of code will break.

See src/share/vm/runtime/orderAccess.hpp for the gory details.


> There are several volatile variables in Hotpot, but it may not really
> work because C++ compilers do not guarantee the visibility or limit the
> instruction reordering.
See the "C++ Volatility" section in src/share/vm/runtime/orderAccess.hpp.


> For example, there is the static variable JvmtiEnvBase:_phase which
> indicates the JVMTI phase in which the JVM is currently in. But AFAICT,
> there is no synchronization used by the callers of get_phase() and
> set_phase() and apparently they can be called by multiple threads. Also,
> the JvmtiEventEnabled::_enabled_bits which is a jlong variable that
> indicates which events are enabled for a single jvmtiEnv. The writes and
> reads to it are not synchronized, either. These are race conditions,
> which implies that some JVMTI event can go off in the dead phase when no
> events are supposed to go off. I'm actually looking into a bug in a
> JVMTI agent that I suspect is due to this.

It certainly looks like JvmtiEnvBase::_phase should minimally be a
volatile; it may also require some sort of synchronization to force
the updated values to be visible...

JvmtiEventEnabled::_enabled_bits also looks problematic. I'm going
to have to mull on both of these and talk to some other folks.

Dan


>
> Thanks,
> Hiroshi
>