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

[Vitaly Davidovich]

>
> 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>