[lworld] RFR: 8245584: [lworld] LW3 core reflection update

[John R Rose]

On Fri, 22 May 2020 19:47:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch updates the core reflection for the new language model for inline classes.
>> 
>> - `Class::isInlineClass` returns true for inline classes
>> - `Class::valueType` returns the value projection of an inline class
>> - `Class::referenceType` returns the reference projection if it's an inline class,
>>     or this class if it's not an inline class
>> 
>> If this class has no val type or ref type, `Class::valueType` and `Class::referenceType`
>> return an empty `Optional`.   We can re-examine  if we should modernize Class API shape
>> where  we can rather than holding to the tradition.
>> 
>> I updated TestIntrinsics.java to use the new APIs for now to keep it compiled.
>> This test will be updated when the intrinsification of the old API `Class::asPrimaryType`
>> and `Class:asIndirectType` is removed.
>
> Hi Mandy,
> 
> The HotSpot changes look good in general, with a lot of nice cleanups.
> You'll find two comments, one minor about hard-coded characters, and a second more significant about the
> `Class::refType` field, for which you might want a review from the compiler team.
> I find it disturbing to have VM code depending on value projection/reference projection fields when these are language
> concepts that are not part of the VM model. but this has nothing to do with your changes, it might be due to the model
> transition, or something we missed in the VM model.  Thank you,
> 
> Fred

It's up to the source compiler to issue or not issue a V.ref class file.  Perhaps the user has manually created one, or
perhaps it is automatically generated, or perhaps the inline type is a HC and therefore cannot have been sealed to a
companion type.

The JVM has to take what's there and surface it; if it's not there the JVM has to carry on.  Since the core reflection
APIs are mostly about what's in the classfile, they don't try to reconstruct what the source language was, but rather
report any and all classfiles present.

But we do want to reflect the relation between V.ref and V.val, if both exist and are properly marked.  We need a
clearly stated rule for what "properly marked" means, and those rules are not nailed down yet, since we are hammering
out a story where V.ref might be either an interface or an abstract class.

I suggest that the final form of the reflection code for V.ref/V.val should be written in Java, and clearly and simply
implement whatever agreement we make in the end. Java code should manage the refType and valType fields, if possible.
Bootstrapping issues may force them to be managed by the JVM, as in this patch, but even in that case the code should
be set apart (probably as a subroutine or two) and documented clearly as relating to the above-mentioned agreement.

One comment, really for the future, regarding the shape of the Java API here:  It uses Optional and omits the "get"
prefix on accessors.  This is the New Style, as opposed to the Classic Style using null (for "empty" results) and a
"get" prefix ("getComponentType") to get a related type.  We may choose to to use the New Style for new reflection API
points, and if so let's not choose N different New Styles, but one New Style.  Personally I like removing "get"; I
accept Optional instead of null; and I also suggest that arrays (if any) be replaced by (immutable) Lists in the New
Style.

-------------

PR: https://git.openjdk.java.net/valhalla/pull/53