LWorld1 initial phase proposal

[Karen Kinnear]

Many thanks.

A couple of points:
> 
> Example:  A field of value type either needs an explicit flatten flag,
> or a Q-descriptor.  The flatten flag (ACC_VALUE) makes an unambiguous
> context for the L-descriptor of the field type, so that it means a Q-type
> rather than an L-type.
Just to clarify: a value type is “flattenable” - the JVM makes the decision to flatten or not -
which may be implementation, platform, command-line-flag, etc. dependent.
> 
>> II. Assumptions:
>> 1. New root: LObject - for all references and value types
> 
> java.lang.Object is a U-type.
> Object classes (other than java.lang.Object) define R-types.
> Value classes define Q-types.
> Interfaces define U-types.
> Abstract classes define R-types.
> 
> The following are possibilities but I hope most of them can be false:
> 
> Perhaps some object classes will *also* imply frozen versions which are Q-types; TBD.
Could we possibly decouple the conversations about immutable classes from frozen instances?
Or am I misunderstanding what the “freeze” behavior would do? I thought the goal was to
freeze a given instance (or array instance) - which does not imply any of the other value-based
class characteristics that we can optimize for.

> Perhaps some value classes will *also* imply heavy-boxed versions which are R-types; TBD.
> Perhaps some interfaces will be *restricted* to Q-types or R-types; TBD.
> Perhaps some abstract classes can help define Q-types or U-types; TBD.


> 
>>   flattenable when contained in reference, value type or array
> 
> "contained in reference" is ambiguous.  I suggest this language:
> 
> flattenable when contained in a variable (instance field, static field, array element, or local)
Much clearer. Thanks.
Current proposal does not flatten in static fields - we don’t expect a significant benefit for that.
> 
>>   support interfaces
> 
> Yes.  Interfaces define U-types.  (TBD whether there are any variations on this theme.)
> 
> And we can say java.lang.Object is an "honorary interface".  It is a U-type
> which all classes implement.  Like interfaces, it is a valid bound for all types
> and all generic variables.
Still trying to figure out what we mean by “honorary interface”?
Not allowed fields?
Can be implemented by value classes and object classes?
Other?

more later,
thanks,
Karen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180103/83aa7e9c/attachment.html>