Re: BC ABI: handling volatile

[Andrew Haley <aph at redhat dot com>]

Andrew Haley writes:
 > Bryce McKinlay writes:
 >  > Andrew Haley wrote:
 >  > > There is one other idea that I am somewhat reluctant to contemplate:
 >  > > always emit a fence when accessing volatiles declared outside the
 >  > > current class.  This might not be so awful, because accessing fields
 >  > > outside the current class is not much done in well-written
 >  > > object-oriented code.  However, these fences can be quite slow on
 >  > > some architectures.
 >  > 
 >  > As ugly as it sounds at first, this actually seems to me to be the
 >  > most simple and attractive solution. I agree that it shouldn't have
 >  > a huge impact on most applications since accessing fields across
 >  > classes is rare. Also, while the barrier/fence instructions may be
 >  > slow, they are probably always going to be faster than a
 >  > "synchronized".
 > 
 > I see the logic.  It's certainly attractive from an ease of
 > implementation point of view, I'll grant you that.  
 > 
 > It sounds like a decent solution for gcc 4.2.

OK, I tried it, and it's nasty.  The problem is that adding a barrier
whenever accessing a field prevents all previous memory references
from being hoisted.  Unfortunately, this includes constant pool and
otable fetches!

So, for this static variable access

   b = a + a;

you turn this:

	movq	_cpool_poo_5_ref.693(%rip), %rax
	testq	%rax, %rax
	je	.L4
	movl	(%rax), %ebp
	movl	%ebp, %ebx
	movq	_cpool_poo_8_ref.699(%rip), %rdx
	testq	%rdx, %rdx
	je	.L9
	leal	(%rbp,%rbx), %eax
	movl	%eax, (%rdx)

into this:

	movq	_cpool_poo_5_ref.693(%rip), %rax
	testq	%rax, %rax
	je	.L12
	movl	(%rax), %r12d
	movq	_cpool_poo_5_ref.693(%rip), %rax
	testq	%rax, %rax
	je	.L13
	movl	(%rax), %ebp
	movq	_cpool_poo_8_ref.699(%rip), %rdx
	testq	%rdx, %rdx
	je	.L8
	leal	(%rbp,%r12), %eax
	movl	%eax, (%rdx)

The memory barrier works for _everything_, not just Java variables.
And, of course, this is particularly horrible if your field access
happens to be in a loop.

It might be that access to fields declared outside the current class
is so rare that this nastiness doesn't matter.  It still might be the
best solution for 4.2.

Andrew.