RFR(M): 8080289: Intermediate writes in a loop not eliminated by optimizer (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Wed Jun 17 20:23:37 UTC 2015

Nope, that's an oversimplified understanding. One place where the JMM will bite you is with publication of object state via final fields. Normal stores used to initialize a structure which is published via final-field semantics must be ordered to take place before the object is published. We don't (and perhaps can't) track object publication events, nor their relation to stores into newly-reachable subgraphs. Instead, we have fences that gently but firmly ensure that data (from normal stores, even to non-final fields and array elements!) is posted to memory before any store which could be a publishing store for that data.

Not sure what's oversimplified -- you're describing a JMM semantic for final fields, which I'd expect to be modeled as barriers in the IR, just like volatile writes would be modeled as barriers, preventing removal or reordering of them. I appreciate that it can be troublesome to track this information, but that only means compiler will have to play more conservative and there may be some optimization opportunities lost. I'd think the pattern would look like:

obj = allocZerodMemory(); // obj has final fields obj.ctor(); // arbitrarily long/complex CFG StoreStore _someRef = obj;

I'd expect redundant stores to be removed as part of ctor() CFG without violating the storestore barrier. But, I do understand the complexity/trickiness of getting this right.

On Wed, Jun 17, 2015 at 3:44 PM, John Rose <john.r.rose at oracle.com> wrote:

On Jun 17, 2015, at 12:39 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

But happens-before is meaningful only for inter-thread communication. If we're talking about plain stores with no fences (or let's say, JMM happens-before inducing points in between them), then as long as intra-thread semantics aren't violated, I'd say anything's on the table :). Nope, that's an oversimplified understanding. One place where the JMM will bite you is with publication of object state via final fields. Normal stores used to initialize a structure which is published via final-field semantics must be ordered to take place before the object is published. We don't (and perhaps can't) track object publication events, nor their relation to stores into newly-reachable subgraphs. Instead, we have fences that gently but firmly ensure that data (from normal stores, even to non-final fields and array elements!) is posted to memory before any store which could be a publishing store for that data. Will this risk uncovering broken user code? Yes, but that code is a ticking time bomb anyway (and subject to CPU reordering as well). Indeed. We live in a world of ticking time bombs. Some of them are our problem even if we didn't cause them. I don't mind uncovering broken user code; sooner is better. But that user will want (as a matter of QOS) a range of workarounds. — John -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150617/408c0558/attachment.html>

More information about the hotspot-compiler-dev mailing list