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)
