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

[Kirk Pepperdine]

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/37d986ca/attachment.html