BC ABI: handling volatile

Thu Jun 15 11:21:00 GMT 2006

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.