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

[David Chase]

On 2012-12-05, at 3:02 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> Bottom-line: it's very easy to confuse the exposure of JVM internals
> with the endorsement of new Java construct. You might as well start the
> rally against Unsafe.allocateMemory because it conflicts with safe
> "garbage-collected" Java.

Aleksey, two things -- #1, the implementation technique used here (unsafe extensions to safe language, with an enforced boundary between them) is not as well known as it ought to be -- it's easy for Kirk to misread this, he's not psychic either.  The C# approach of (last I checked) allowing the sprinkling of "unmanaged" blocks into ordinary code does not help, since it often gives the impression that "unmanaged" is for anyone to use, if their style-checker is not currently forbidding it, and wouldn't you like your Very Important Loop to run a little faster?

#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.  It is not unlikely the (flawed) original Unix approach to security, where a single flag controlled access to everything, and there are no shades of gray.  Careful organization helps us avod accidental incorrect use of truly Unsafe features.

For example, there is Unsafe-can-bork-the-VM ("poke"), Unsafe-can-subvert-security ("peek"), and Unsafe-can-see-implementation-quirks ("rawbits").  Some unsafe operations can result in denial-of-service if used inappropriately (infinite loops with no safepoints, for example).  Another variant might be not truly unsafe, but only "work" for a difficult-to-document set of inputs.  Both the fences and contended fall into another category, where the user cannot do any semantically bad things, but might create difficult-to-understand performance problems that we really don't want to bother with explaining to most users (@inline is another example).

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've seen some Unsafe howlers committed by "experts" over the years in other programming languages.   Because this is open source, we have some external self-appointed experts who are using Unsafe stuff already when they think it is important to their application.  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. 

David