Re: BC ABI: handling volatile

[Andrew Haley <aph at redhat dot com>]

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.

 > Also, going this route in no way precludes switching to a more
 > sophisticated implementation later, should it prove necessary - the
 > old code will still work just fine.

It's the ABI design implications that interest me ATM, even if we use
a simple workaround now.

 > Perhaps we can add an -fno-volatiles flag so that the impact of
 > this can be easily measured, or so users who know their code does
 > not use volatiles can optimize.

I'm opposed to any "generate incorrect code" flags for gcj.

Andrew.