LWorld1 initial phase proposal

Karen Kinnear karen.kinnear at oracle.com
Wed Jan 3 16:59:05 UTC 2018

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?

more later,

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

More information about the valhalla-spec-experts mailing list