RFR (S): CR 8004318/JEP 171 Fences intrinsics

[Vitaly Davidovich]

Hi Kirk,

I'd expect *responsible* developers will use some hardware event profiler
and/or experimentation to determine whether there's false sharing and
padding actually helps the workload they're optimizing.

If your concern is some people will simply guess and slap the annotation
all over the place, then I don't think you can really help cases like this;
such folks are likely to create a mess of anything they do if they're in
the habit of guessing.  I don't think the java platform should cater to
that as it's no longer a technical problem but a people one.

Thanks

Sent from my phone
On Dec 17, 2012 4:37 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> Hi Aleksey,
>
> I half agree with you on the orthogonality comment. But you know my
> mantra.. "Measure, don't guess" and what these JEPs are saying, no
> screaming... lets guess!!! I've been quiet because 1) I've not had the time
> to offer well thought through or even half-baked alternatives and 2) these
> JEPs do provide functionality that I recognize is necessary. That said,
> this functionality is only useful under certain conditions that are only
> visible in the run time environment. If those conditions change for any
> reason, it's unclear what the effects of these "optimizations" will have on
> the run time. This implies a trip back to the code to correct a guess that
> has been incorrectly made. Almost analogous to a developer deciding it's a
> great time to call System.gc(). They maybe right... and certainly in some
> cases they *are* right. So, I wouldn't want to take the ability to call
> System.gc() away from developers. That said, I'm very happy to have the JVM
> decide to make that call on it's own 'cos that often works out much better.
> Ok, knowing that memory is full is easy to sort out especially compared to
> the false sharing problem. That said, giving programmers an annotation to
> deal with it without adding the heuristics into the JVM to eliminate it in
> the first place or at least a flag or MXBean to allow for some control in
> the run time feels funny. Not having a way to get a measure to expose that
> you have the problem in the first place simply feels wrong. Hence, the tie
> in. If we're going to expose this low level stuff than we also need to
> think about a measure to say you're suffering from that problem. That is
> what's missing from this JEP assuming we can't bury this functionality into
> the JVM it's self. If we need a complimentary JEP to cover this off I'm
> happy to start a new document.
>
> -- Kirk
>
> On 2012-12-17, at 10:07 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com>
> wrote:
>
> > On 12/17/2012 02:32 AM, Kirk Pepperdine wrote:
> >> I think we should consider giving people access to the MSRs.
> >
> > This is at very least orthogonal, if not completely unrelated to Fences
> > discussion. You should consider filing the JEP for exposing MSRs and
> > work there to discuss the Java MSR support.
> >
> > -Aleksey.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121217/fb415aff/attachment-0001.html