CNI changes (Was: Binary Compatibility)

Mon Aug 4 18:39:00 GMT 2003

I'm the HP representative on the JSR 133 EG.
I think the following changes are likely to be required to support the new memory model:
0) I don't know if the back end can combine writes to byte fields close to each
other, or implement a byte write using a wider store instruction. If so, this
should be turned off. (In my opinion, not just for Java.) 
1) Loads and stores of volatile longs and doubles must be atomic. This was
always a requirement. On 64-bit machines this is usually automatic. For X86,
volatile longs require care. Some VMs apparently load values into the fp
registers first, to avoid locking.
2) Volatile loads and stores must have acquire/release semantics. The compiler
shouldn't reorder them with respect to other heap operations. Depending on the
architecture (and on how you read the X86 architecture spec) a memory barrier may
be required after a volatile load and/or before a volatile store. On IA64,
treating them as C volatiles works, except that:
3) All volatile operations must become visible in program order. This includes the case of
a volatile store followed by a volatile load. Thus volatile stores must, in the general case,
be followed by a barrier. This applies also on X86, where it's likely to require a dummy
chg instruction or similar. (This is possibly a controversial
requirement. It's arguably not terribly useful in real apps. But it significantly
simplifies the programming model. I think it would be significantly harder to teach
Java concurrent programming without this rule.)
4) There are fairly complex rules to ensure that if I (1) construct an object with
final fields, and then (2) store the only reference to the resulting object to
a shared location, any thread that sees the pointer to the object will also see
correct values for the final fields. My understanding is that on architectures like
Itanium, this will usually require a memory barrier at the end of a constructor
that initializes final fields. On Alpha, it will unfortunately also require a read
barrier before a load of a final field. (Alpha appears to be the only architecture
that requires this.) With the de facto X86 spec, no barriers should be required.
(My reading of the official spec is that it requires the same treatment as Alpha.
But nobody seems to believe that.)
In my view, (4) is likely to have the largest performance impact, since everything
else is restricted to volatiles, which are generally rare. (That of course is
due in large part that they generally haven't been correctly implemented, but ...)
The problem is that without (4), there seems to be nothing to prevent a file name
from magically changing out from under you, between the time you did the security
check, and you perform a file operation. Which is not good.
There are a bunch of additional details in Doug Lea's page:
http://gee.cs.oswego.edu/dl/jmm/cookbook.html
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Monday, August 04, 2003 10:45 AM
> To: Andrew Haley
> Cc: Tom Tromey; Anthony Green; java@gcc.gnu.org
> Subject: Re: CNI changes (Was: Binary Compatibility)
>>> On Mon, 4 Aug 2003, Andrew Haley wrote:
> > This is all rather system dependent AFAIK.
>> Yes definitely. Much like "volatile" semantics (which 
> currently does the
> right thing on IA-64 but almost nowhere else AFAIK).
>> It may be helpful to have a document on what is required for a GCC
> target to implement the Java memory model correctly, and 
> identify some of
> the problem cases (e.g. lack of byte load/stores, as in Alpha EV4).
>> That said, GCC developers might not be so receptive, judging from the
> reluctance towards Ada features in the backend.
>> Jeff
>