[foreign-memaccess] RFR 8228447: Remove kinds from value layouts

[John Rose]

Good simplification.

FTR, kinds were in some early versions of the layout design as explained here:
  http://cr.openjdk.java.net/~jrose/panama/minimal-ldl.html#kann

More background, FTR:

The idea is that memory layouts, for small items, are loosely coupled to the machine registers into
which they are loaded.  (After all, memory layouts are relatively useless unless their elements can
be loaded *out* of memory *into* something else.)  So the float vs. int distinction is useful because
many CPUs make a distinction between those kinds of registers.  The distinction becomes important
when you spin code to load or store such elements.  In today’s APIs, that distinction is driven by
(Java) carrier type, so it doesn’t need to be present in the layout.

More distinctions can be made relative to the registers into which memory data are loaded, once
you realize that “registers” don’t have to be actual physical hardware resources; a “virtual register”
is really an optimizable container or named/numbered value outside of alias-able memory, something
a VM or JIT can get a handle on without worrying about alias conditions, races, and mutability.

A virtual register can have a size which differs from (is larger than) the memory element it contains.
E.g. a memory byte can be loaded into a 64-bit register.  This immediately motivates a distinction
between signed and unsigned ints, which are padded using distinct conventions (and loaded using
distinct instructions on most platforms).  Vector registers are a different kind of container.  And bitwise
images of structs are yet another kind of (virtual!) container.  Varargs conventions seem (to me) to
introduce more container types as well, since their values are manipulated (by VMs and JITs)
according to peculiar conditions discussed elsewhere.  Even machine pointers seem to be
distinct enough from floats and ints to merit a kind, in some accounts, because they have their
own conversion rules which may or may not be the same as sign or zero extension.

I think all of these distinctions can be driven (and are now driven) from carrier types and other
bits of API context.  But it’s useful, sometimes, to think of the as their own set of concepts,
distinct from and decoupled (in principle) from API binding details.

— John

> On Jul 19, 2019, at 10:17 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi,
> this patch removes the Kind enum from ValueLayout - and consolidates the various ValueLayout factories even further:
> 
> cr.openjdk.java.net/~mcimadamore/panama/8228447/
> 
> (this is based on top of the patch for 8228444).
> 
> I like how it simplifies the API, and removes the float/int/signed/unsigned from the equation which, as Jorn pointed out, wasn't  really used anywhere.
> 
> Maurizio
>