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

[Vitaly Davidovich]

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/20121205/59f4782f/attachment.html