Re: Double check locking

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Tom Tromey wrote:

> > > > > > "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
> > > > > >            
> Jeff> If all static members can be addressed at constant offsets from
> Jeff> the class pointer, that takes care of the class initialization
> Jeff> test we do now.
>
> Could you explain this to me?  It seems to me that we'll still need a
> test, because the class will be dynamically created.  So at an active
> use site we'll have to see if it has been created, presumably by
> making a synchronized method call.  Hopefully I'm missing something.
There will have to be checks at active use sites but no syncronization 
is required, unless of course if the class actually needs to be initialized.

In binary compatibility mode each translation unit would have a local 
table of pointers to the classes which it calls. This would work similar 
to the otable we have now for indirect dispatch except instead of being 
filled out with virtual method offsets it would be filled with actual 
class pointers. At each active use site (and hopefully gcj can be 
smarter about what those are with higher level inlining etc), it will 
just test the class entry for null and call a 
_Jv_GetClassPointer(class_table, index). This function would effectivly 
do a Class.forName() and put the class pointer in the right slot in the 
class table. I imagine the actual code to do this would be similar in 
size to what we have now, but less GOT symbol references and such will 
make the binary object size significantly smaller.


> Hmm, right now we seem to do "double checked locking" when checking
> the class initialization status.  At least that's what it looks like:
>
> 	cmpb	$12, _ZN4java4lang6System6class$E+74
> 	setge	%al
> 	movb	%al, -1(%ebp)
> 	cmpb	$0, -1(%ebp)
> 	jne	.L3
> 	movl	$_ZN4java4lang6System6class$E, (%esp)
> 	call	_Jv_InitClass
>
> Isn't that a no-no?
I believe "double check locking" is/was considsered unsafe in Java 
because the Java spec didn't specify well enough how "synchronized" 
works with respect to coherent memory. There was a proposed memory model 
extension to make the Java spec specify how synchronized and volatile 
work in more detail.

AFAIK, in libgcj, double lock checking is safe provided that our compare 
and swap implementations have barrier semantics - ie memory reads after 
the swap do not occur until the lock is aquired and memory writes are 
committed before the lock is released. I believe all the libgcj 
compare_and_swap implementations do this.

(BTW last time I checked gcj was only doing this type of check in some 
cases. It still generates a lot of unconditional _Jv_InitClass calls too)

regards

Bryce.