RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe

[John Rose]

On Jun 29, 2018, at 3:14 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> I like the caveat "as long as the intermediate breaking effects
>> are contained and cannot be observed externally”, but I’m
>> curious to know how it will be checked or enforced.

Yes, that's exactly what I meant by the design constraint that an
Unsafe API must be usable in a safe manner; you could call the
the Unsafe Prime Directive.

See my previous message for how to implement this directive for
value patching:  You need a pair of intrinsics for privately buffering
a value, and for committing such a buffer to be shareable.

In the JIT, they would be implemented using some sort of fencing,
perhaps with an internal mode change (from ValueNode to
ValuePtrNode or the like).

> With great care and good testing. Some of the code in j.l.invoke plays this dangerous game.

(If you like, think of Unsafe as the C++ Access API hiding in Java.
The same mind set is required for using either.)

> I wish there could be a way of more formally marking a block of such internal code beyond clear use of the Unsafe class.

A bit of history:  Over various objections similar to the present ones, I created
the sun.misc.Unsafe API (first commit 2000/04/01, not a prank).  The goal was
(and is) to allow Java code to play on C++'s territory.  Even back then we were
getting tired of writing new bespoke natives and C++ code for every incrementally
edgy new idea for a Java API.  (That was also when I began to dream of an
all-Java implementation of HotSpot a la Graal/Metropolis/Maxine/Jikes, and
wonder when that researchy idea would be mature enough to emerge from
somebody's labs.)

At the time I was aware of the unsafe-block feature in some research languages,
and, with fear and trembling, instead designed a dynamic capability-based
permission check, to properly delimit and check code which uses this super-user
API.  At the time piggy-backing a capability check on the JVM null check was
an unproven technique.

It seems to have worked.  You can find unsafe blocks fairly easily in Java simply
by looking for uses (import, CP entries) of Unsafe.  In the end, and combined with
Java 9 modules, I think it's not terribly worse than an unsafe block with an unsafe
marker attribute on code.  When you see Unsafe, it means "Don't fiddle with this
if you don't know what it does, but if you do know what you are about, you are
in super-user mode; bring your own seat belt."

> —
> 
> I view Unsafe as a far far less formal equivalent of Rust’s unsafe block [1] for us Java Runtime engineers to build a safe and performant platform. I guess the closest formal notion with have currently is JNI :-) soon we will have Panama and that will up-level some unsafe properties of JNI and native wrappers into Java code.

Yep.  Actually Panama re-raises the question of clearly marking Java code which
needs extra analysis to verify safety (null, bounds, lifetime, type, etc.).  One way
to secure Panama code would be to require an Unsafe instance to do anything
with a Panama binding.

— John