RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

[Andrew Dinn]

On 17/02/15 19:21, Vitaly Davidovich wrote:
> IMO I don't think such barriers should be removed just because EA is able
> to elide the heap allocation.

Why not? Are you assuming that the programmer might be relying on a
memory barrier being implied in interpreted/JITted code by the presence
in the source of an allocation? If so then I am not sure the Java memory
model justifies that assumption, especially so in the case EA optimises.

As I recall, the arguments here and on the concurrency lists for the
presence of a memory barrier at the end of allocation were only /for/ it
as a heuristic to ensure that objects which might be shared would not be
shared before all effects of construction were visible (I may be
misstating that -- you might like to reread it as "the arguments on the
concurrency lists I was convinced by" :-). In which case, if an object
cannot be shared, indeed need not even be allocated, then there appears
to be no need for such a heuristic.

n.b. if a Java programmer really wants to enforce memory ordering wrt
other threads then Java provides a very simple mechanism for that in
volatile.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)