synchronization of JVMTI phase notifications [Fwd: Data visibility between threads in Hotspot]
Daniel D. Daugherty
Daniel.Daugherty at Sun.COM
Wed Feb 11 12:43:55 PST 2009
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
>
More information about the serviceability-dev
mailing list