minimal value types proposal

[John Rose]

On Aug 31, 2016, at 11:59 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> I have updated of this document to reflect comments so far.
> It is stored to CR (in place) and enclosed here.
> — John
> 
> Link:  http://cr.openjdk.java.net/~jrose/values/shady-values.html
> 
> <shady-values.html>

I have updated the document again with small corrections and clarifications.
Enclosed is not the whole file, but a selection of the diffs from the markdown.
As always, the full file (HTML and MD) is available on-line, or by private request.

Thanks to everyone who has commented so far!

— John

@@ -43,11 +43,17 @@
  - clarify status of field ops (getfield, etc.)
  - table for new MHs, link to "bytecode behavior" table
  - futures paragraph on u* codes
- - decribe class-splitting load transform
+ - describe class-splitting load transform
  - loosen the specified coupling between Q-type and L-type or box
  - java.lang.{Class,reflect} APIs radically minimized for value types
  - decouple box-class from source-class, warn about box futures
  - consolidate ValueType and ValueTypeSupport
+2014-09
+ - remove typos, bugs, solecisms
+ - clarify POJO status of value-capable (pre-split) class
+ - emphasize the range of implementation options for class-splitting
+ - clarify status of Q-types in getfield (etc.), add rationale
+ - clarify temporary role of invokedynamic and MHs
 -->
 
 #### John Rose, Brian Goetz

@@ -191,7 +197,14 @@
 
 As with the full value type proposal, the value-capable class may
 define fields and methods and implement interfaces.  The fields and
-methods will be available directly on both boxed and unboxed values.
+methods will be (at least at first) logically duplicated from the
+boxed to the unboxed value types.
+
+The value-capable class may use JVM extensions (new descriptors or
+constants) described in this document, but in fact _the value-capable
+class may be an ordinary plain old Java object (POJO) class_, and it
+will still be able to define a useful value type.  This property makes
+value-type programming feasible with existing tools, unmodified.
 
 > <span class="smaller">
 (Until there are bytecodes for directly accessing members of unboxed

@@ -313,7 +328,9 @@
 that the JVM takes extra care to redirect these references to apply
 inside of the synthetic `$value` field.  This can be done by bytecode
 rewriting, by modifications to resolution logic, or any equivalent
-technique.
+technique.  The field extraction may be done by the JVM's native class
+loader, by an instrumentation layer, by a static rewrite, or by any
+equivalent technique.
 
 As will be explained below, the value type needs no direct method
 definitions, as long as method logic from the original class can be

@@ -692,6 +708,20 @@
 In a fuller implementation of value types, some of these (but not all)
 are candidates for interoperation with Q-types.
 
+> <span class="smaller">
+It may seem odd to allow Q-types to move through method calls (via
+`vload`, etc.) and not through instructions like `putfield` or
+`getstatic`.  The asymmetry is due to the special complexity of
+field-access instructions in the interpreter.  Leaving that untouched
+probably gets us to a prototype faster.  Supporting Q-types as method
+arguments and returns is also complex, but once that bit is done,
+method handles can take over all other aspects of execution, including
+field access.  In addition, the present minimal design has the virtue
+of not requiring the interpreter to ever deal with the flattened form
+of a value; it can use opaquely boxed pointers for function calling
+and never even care about the size or format of the values it is
+working with.  This is a temporary but significant simplification.
+
 ## Value type reflection
 
 The public class `jdk.experimental.value.ValueType`

@@ -929,6 +959,14 @@
 Q-types (represented as `Class` objects), and surface methods which
 can perform nearly all of these functions.
 
+> <span class="smaller">
+It is sometimes helpful to think of these operators as the missing
+bytecodes.  They can be used with the `invokedynamic` instruction to
+emulate bytecodes that experimental translators may need.  Eventually,
+some form of many such bytecodes will "selectively sediment" down
+in to the JVM's repertoire of bytecodes, and usage of `invokedynamic`
+for these purposes will decrease.
+
 Pre-existing method handle API points will be adjusted as follows:
 
   * `MethodType` factory methods will accept `Class` objects