(original) (raw)
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@oracle.com> wrote:
On Jun 17, 2015, at 12:39 PM, Vitaly Davidovich <vitalyd@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