updates for May 10 meeting

[John Rose]

Responses to AIs in Karen's previous minutes are embedded.

On Apr 26, 2017, at 12:49 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Next meeting May 10th: dial-in: https://oracle.zoom.us/j/251372518 <https://oracle.zoom.us/j/251372518>
> 
> Notes from April 26:
> Attendees: Remi, Dan H, Bjorn, Doug, John, Vladimir, Frederic, Karen
> 
> AIs:
> 1. John - please update Shady

Updated, backlog is a couple of weeks of comments.

> 2. All - please review email rough proposal for load/link/init behavior for MVT

Response sent.

> John: Even if we moved to typed bytecodes today, we would still expect changes
>   note: values are inherently polymorphic post MVT - e.g. interface support
>   looking at a 6th BasicType. Interpreter will need to have full type information with the type,

Firmed up this position in Shady, a little.  I note that in our prototype the
vfoo bytecodes (Q-mode instructions) are mercifully free of references to
their types.  I want to continue this.  This means that under the hood there
is a true polymorphic "Q-buffer" type that all these guys operate on.
This type is Q-Object or "Qjava/lang/__Value;" or some such.
I think this type is too useful to keep in the JVM; it will show up in the
future as the bound type for polymorphic any-vars, and should be
used right now to erase lambda-forms.

> 
> 3. Karen: Do we have a need for a QFoo in a field descriptor?
> We support QFoo in a method descriptor as well as [QFoo in a field descriptor.
> Concern: reflection and tooling exposure to value types
> Lesser concern: implementation complexity
> 
> Responses:
> Remi: If play with optional, want to store in a field (note: not supported today)
> Remi: monad - not want to pay abstraction
> 
> Frederic: workaround is to use an array of 1 element
>           given we are not flattening, there are no density or lack of indirection benefits of supporting
> Doug: Ask Scala folks or Martin Hadusky (sp?)
> John: propose as side project - i.e. target of opportunity, but not planned for MVT
> Bjorn, Karen: have experimented with it, ok as side project

Shady waffles on this.  Still needs work to clarify.

> 
> 4. new root type for values
> We needed this internally for LambdaForms to avoid specializing per value type.
> Initially we are calling this java/lang/__Value
> At this point this is not a global root, but a root for value types only
> Exposing this so that MethodHandles can use this is a big step.

Little discussion of this in Shady.  Some discussion of top types as U-types.
I owe a separate position paper on carrier types and {U,Q,L}-{Object,interface,class}.

> 5. question from last tim about verifier checking for complete instances of values before letting them go.
> John's answer: No - verification is not needed here. See next update of Shady.
> 
> [ed note: see load/link/init email proposal - I think we are in agreement that there is no such thing
> as an uninitialized value type]

Updated in Shady.

http://cr.openjdk.java.net/~jrose/values/shady-values.html
http://cr.openjdk.java.net/~jrose/values/shady-values.md

Summary of changes:
 - make relations between VCC and DVT much more definite
 - VCC is just a POJO; DVT derivation is decoupled from VCC loading
 - push DVT down beneath the woodwork: it has no separate name, mainly a view of the VCC
 - ditch the much-unloved ";QFoo;" syntax for CONSTANT_Class (use context instead)
 - link to more focused draft JEP on CONSTANT_Dynamic (forthcoming)
 - distinguish between primary (proper) mirrors and secondary (improper) mirrors
 - discuss DVT initialization and its triggers
 - clarify that the JVM does not try to enforce complete initialization of values
 - update bytecode descriptions to better match Valhalla prototype
 - simplify reflection:  no sourceClass, VCC does everything as a POJO
 - reminder: all this will change
 - under "more bytecodes" add guidance on carriers and U-types


— John