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

[Kirk Pepperdine]

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