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

[Kirk Pepperdine]

Hi,

I think we should consider giving people access to the MSRs.

As for dumbing things down.. that is the wrong way to deal with these low level issues. However, in the absence of a real measure people will guess at when an optimization should be applied. Should an optimization be applied? That depends on what the MSRs say.

Regards,
Kirk
PS, I am looking forward to being able to test out these new features *even if*, I have reservations that this is the best way to expose them but....

On 2012-12-05, at 5:12 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi Kirk,
> 
> Your comments seem to be one of the more loudly opposed ones.  So we know what problems @Contended and Fences are trying to fix.  Do you have any actionable alternatives to suggest? I'm sure everyone would agree that if these things could somehow fit into java better, then we'd all prefer that over JVMese approach.  But nothing has been put forth by the folks opposing this.  Simply wishing for something or saying "let's think about it" won't help - who is going to think about it and then do something?
> 
> At the end of the day, there will probably always be some things that can be expressed better by peeling away the layers of abstraction from Java proper.  I think it's unreasonable and unrealistic to think that java will provide access to low-level details of the underlying hardware - this is at odds with the design of the language.  However, the JVM is fast enough that a lot of people are using it to build high performance software.  In that space, it's always nice to eek out that extra level of perf, even if you're now stepping out of the "safe" zone.  I personally don't see anything wrong with letting people make the decision to go there - it's not an accidental venture, and they make the leap with all the warning labels in their face.  What I don't think java should solve is a people problem - if developers plunge into this space without thinking it through and doing analysis, that's their problem, frankly; nobody forced their hand.
> 
> If the philosophy is to dumb down the platform to prevent people shooting themselves, then we should also get rid of a bunch of existing constructs/knobs in the JVM.  There are plenty of Hotspot cmdline flags that can be considered low-level and could be played around with by people not understanding them that can have worse problems than @Contended.
> 
> It's also interesting that in the C# space, which has had unsafe options almost from the get go, I have never heard anyone complain about it.  In fact, Mono even went further with providing SIMD intrinsics in their library and that's only been praised (from what I've seen).
> 
> Cheers
> 
> Sent from my phone
> 
> On Dec 5, 2012 10:51 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:
> Hi Aleksey,
> 
> 
> On 2012-12-05, at 2:56 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> > On 12/05/2012 05:20 PM, David Chase wrote:
> >> #2, a restatement of a previous complaint (that I will let slide for
> >> now, but will bring up in the future again when we have time for
> >> cleanup and reorg) is that we need to be quite careful about the
> >> distinction between the various sorts of Unsafe.
> >
> > Totally agree. Now to constructive side: are you up to actually clean up
> > Unsafe? *This* makes a perfect JEP to have the open discussion about.
> 
> To my knowledge, n the history of the JDK.. no public exposed API has ever been cleaned up. Once exposed it will be used and once used it will be impossible to back off of it. Thus prudence needs to be preferred over expedience. What makes you believe that you will be able to clean Unsafe in the future?
> 
> >
> >> There's a natural tendency to say "we're on the implementation side,
> >> we know what we're doing, this organizational stuff is not a good
> >> use of our time, we have deadlines to meet" -- and I hope your
> >> response is the eye-rolling "yeah, right".
> >
> > I understand this concern, but this might as well serve as the excuse of
> > not doing anything at all, and only "exploring alternatives" for years,
> > while key developers are fleeing away from the platform (I've almost
> > used word "vibrant" here!).
> 
> Do you have numbers to support this assumption that developers are fleeing. The way I see it, more and more people are understanding the advantages of the platform and are moving to adopt it. I'm seeing more and more code ported from C++ to Java for reasons of maintainability etc.... This is not an excuse to not do anything but to properly resource and look into a safe solution to a known deficiency. I would like these things to be solved but I also believe there is a way to solve them in the context of how Java functions. The VM has proven time and time again that being adaptive to the run time has provided many many benefits that are not reachable by average developers.
> 
> >
> > In fact, for fences, it was on the table for at least 3 years, and no
> > better+practical approach emerged. That is why I get sincerely amused
> > when somebody wants to have the discussion about fences again, and get
> > double amused when exposing the intrinsics to out-of-band internal API
> > somehow promotes to "omg, that breaks Java" stunts.
> 
> Sorry to say this but I find this attitude both offensive and counter productive to community building.
> 
> I will be giving a talk on concurrency at the Munich JUG in a few hours. We will talk about fences and I will show them how to do pointer manipulation in Java.. and how it can be used to implement wait-free, non-blocking algorithms.. I will show them how to get measurements to understand when their applications are fighting with the hardware... That said, I really wished that we had a better... safer way to achieve the same effect than exposing people to unsafe.
> 
> Kind regards,
> Kirk Pepperdine

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121216/6ad7070c/attachment.html