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

[Vitaly Davidovich]

So I think everyone's in agreement that for any feature X, if JVM could do
it better or automatically, then people would take that over manual knobs.
However, unfortunately the JVM isn't some magic pixie dust - someone has to
go and implement said feature, test it, and support it.  In cases where you
have a quick and simple way to enable the feature vs something much more
involved that perhaps adds only marginally better experience and will take
much longer to release, it's almost a no brainer to do the quick and easy
one and then see how it pans out before plunging head first into the
complex/longer variant.  It just may be that people using it will find
supplemental tools to make the experience better, and don't need the JVM to
do it; in this case, the supplemental tool would be hardware event
profilers, which people may already be using anyway.

Cheers

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

> Hi Vitaly,
>
> Despite the seemingly mothering nature of my recent email posts, I don't
> really buy into that attitude. I'm ok with Unsafe being there as it serves
> purposes that we've (unfortunately) not found a safer way to present to
> developers that need it. That said, my concern isn't about those that may
> slap these annotations every where (for me that is a business opportunity).
> I'm of the mind that the JVM comes to the table with more information than
> I have and even what reasonable developers have *even with careful
> experimentation*. If you can buy into that then it seems to me that I'd
> rather have the JVM decide that something should be padded rather than 1)
> have me experiment to discover it and then 2) correlate that experiment
> with some bit of code, 3) alter the code and then 4) hope that conditions
> don't change to something that invalidates my correction and 5) would
> prevent me from monitoring and re-experimenting to make sure my correction
> still applies. If there is no magic to look after all this, I'll take the
> annotation.
>
> Regards,
> Kirk
>
> On 2012-12-17, at 1:31 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> 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/ba2a43cb/attachment.html