Double check locking

Boehm, Hans hans_boehm@hp.com
Tue Jun 11 10:13:00 GMT 2002


To clarify the issue:

My impression is that we are careful in the initialization code that the actual initialization precedes the setting of the klass->state.  That's fairly cheap to get right anyway.  The question is if in code like

	(1) if (klass -> state != JV_STATE_DONE) ...
	(2) read initialized data from klass

the read of the state variable in (1) is guaranteed to precede the reads in (2).  I believe the answer for esssentially all modern architectures is "no".  (See for example ftp://download.intel.com/design/Pentium4/manuals/24547207.pdf, S 7.2.2 "1. Reads can be carried out speculatively and in any order. ...")

The right way to handle this is almost certainly to treat "klass -> state" as a Java volatile, and get Java volatiles to work correctly, as in the new proposed Java memory model.  Volatile reads should enforce ordering between that read and subsequent memory accesses.  On Pentium 4, I believe this requires a memory barrier.  On Itanium, volatile reads should be implemented with ld.acq.  (On Itanium, it also matches the semantics of C volatile.  Unfortunately, this isn't universally true.)

If instead of checking a flag, we indirect through a class pointer, and check whether that against null, the rules change slightly.  In that case, we would be concerned about the ordering of reads

x = classes[i];
y = x -> static_field;

These are guaranteed to be order on Itanium due to the data dependence.  I couldn't quickly find a statement that they are ordered on P4.  They are NOT ordered on Alpha.  (See Bill Pugh's web site for details.)

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Tuesday, June 11, 2002 8:38 AM
> To: Bryce McKinlay
> Cc: Jeff Sturm; Boehm, Hans; java@gcc.gnu.org; boehm@acm.org
> Subject: Re: Double check locking
> 
> 
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> 
> Tom> I think the check in the _Jv_InitClass that gets inlined 
> isn't safe.
> Tom> At least, it doesn't make any apparent attempt to be safe.
> 
> I mean, the code in emit_init_test_initialization() that generates the
> tree in question.
> 
> Tom
> 



More information about the Java mailing list