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

Tim Bell Tim.Bell at Sun.COM
Tue Feb 10 17:10:01 PST 2009

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.

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.

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.


More information about the serviceability-dev mailing list