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

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Dec 5 05:56:02 PST 2012

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.

> 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!).

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.

> If nothing else, profligate use of "Unsafe" increases the amount of
> code that must be reviewed with a microscope, when only a magnifying
> glass is necessary.

Totally agree x2. Again, do we want to push away fences from Unsafe to
make the room for cleaning up Unsafe? If so, would be it better to move
fences to, say, sun.misc.Fences? Seems to fit the bill for what you are
suggesting of splitting up the Unsafe?


More information about the hotspot-compiler-dev mailing list