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

[John Rose]

On Jun 27, 2018, at 3:11 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> I was hacking around with an alternative based on your code that creates separate methods (with lighter checks pushed to asserts, but i almost removed ‘em):
> 
>  http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/ <http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/><http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/ <http://cr.openjdk.java.net/~psandoz/valhalla/unsafe-flat-value-access/webrev/>>
> 
> The general idea being one could write or read a value to or from an area of memory, it's up to the caller to pass in the correct arguments. So that in principle works for flat fields, flat arrays, or off-heap. However, i don’t understand the the value type code in detail so perhaps such an approach is misguided?

Yep; container types should be explicit and required from the user of Unsafe.
(That's what you call "layout" and I call "valueType".)

One hallmark of the Unsafe API design is that assertions like you mention
can be coded which will help catch user errors, but the assertions can safely
be disabled without changing semantics.  After assertions are dropped,
what's left can be optimized readily by the JIT, often to an instruction or two.

The JVM is clever about hiding the internal formats of its objects, but those
formats ("layout" is a good term) need to be available to Unsafe users.

We can assume that Class<?> is a reasonably future-proof way to reify those
decisions to Usafe users.  The layout of a reference field can be Object.class regardless
of any narrower type of the field (and even if the field is typed as a non-flat value).

— John