[lworld] RFR: 8244231: [lworld] Add support for ref-default and val-default inline classes.

[Srikanth Adayapalam]

On Wed, 21 Jul 2021 12:00:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1381:
> 
>> 1379:                 }
>> 1380:             }
>> 1381:             return flavor == Flavor.Q_TypeOf_L;
> 
> Shouldn't we discount primitive-default primitive classes in here? (e.g. should this code be symmetric with `isReferenceProjection`?). E.g. what about `.val` in an already primitive-default primitive class?

W.r.t the observation: "I'm also a bit unsure (and left comment) on whether isReferenceProjection and isValueProjection are implemented correctly. They do not seem to be the dual of each other at the moment (or at least do not seem to do what the javadoc says they should)."

Please take a another look! I believe they are dual of each other and do what the javadoc claims - (although as I call out below, I am open to questioning whether their behavior should be redefined)

ATM, the javadoc of isReferenceProjection() and isValueProjection() read:


    /**
     * @return true IFF the receiver is a reference projection type of a *value favoring* primitive class
     * and false otherwise. Or in other words, is this a class type non-redundantly notated with .ref ??
     */
    public boolean isReferenceProjection() {
        return false;
    }

    /**
     * @return true IFF the receiver is a value projection of a *reference favoring* primitive class type
     * and false otherwise. Or in other words, is this a class type non-redundantly notated with .val ??
     */
    public boolean isValueProjection() {
        return false;
    }



You ask of com.sun.tools.javac.code.Type.ClassType#isValueProjection

Shouldn't we discount primitive-default primitive classes in here? (e.g. should this code be symmetric with isReferenceProjection?). E.g. what about .val in an already primitive-default primitive class?


We *are* already discounting primitive-default classes, because in that case the flavor would be Q_TypeOf_Q.

The ambiguity exists only for the flavor L_TypeOf_Q - when we have a type that is an L_TypeOf_Q it could be
either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.   

Of (a) and (b) only (a) we consider to be the *reference projection* as per the javadoc.

On the other hand:

Between Q_Typeof_Q and Q_Typeof_L, only the latter is considered a value projection as per the javadoc.

(Backing up a bit it is a fair question to ask should the javadoc be defined that way - should both Q_Typeof_Q and Q_Typeof_L be considered value *projections* and should L_TypeOf_Q should *always* be considered a reference *projection* irrespective of whether the associated class is a reference default or value default ? I have chosen not to since that seems "natural" - but I am open to revisiting this if our experience proves otherwise.

Please see that this is the same issue JEP 401 grapples with by asking the question in https://openjdk.java.net/jeps/401

(Open question: should it be legal to redundantly apply .val to a standard primitive class name, or .ref to a reference-favoring primitive class name?)

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

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