hg: valhalla/valhalla: 8221545: [lworld] Preliminary support for alternate denotation of values and boxes

Wed Apr 17 18:14:45 UTC 2019

As a pointer, I think V -> V? should be part of Types.isSubtypes, 
whereas V? -> V should be in Types.isAssignable.

That should fix overload resolution too

Maurizio

On 16/04/2019 15:53, Srikanth wrote:
> Sounds good. I will work on implementing these (except for the source 
> level express cast). I expect to have a fix by early next week.
>
> Thanks
> Srikanth
>
> On 16/04/19 8:07 PM, Brian Goetz wrote:
>> Let’s separate the language and VM aspects.
>>
>> In the language, since V <: V?, no cast is needed when assigning a V 
>> to a V?.  And no CHECKCAST is needed for the corresponding code 
>> generation.
>>
>> In the other direction, a CHECKCAST is definitely needed going from 
>> V? to V; the question of whether the _language_ requires an explicit 
>> cast is still up in the air.  I think we should lean on explicit 
>> casting for now, but I suspect we’ll slide back to implicit narrowing 
>> (with possible NPE).
>>
>> This also makes a difference for overload selection.  If I have:
>>
>>      m(Object o) { }
>>      m(V? v) { }
>>
>> and a call
>>
>>      V v = …
>>      m(v)
>>
>> Under the old (V.box) interpretation, we’d prefer the m(Object) 
>> overload, since it is applicable without a boxing conversion, and 
>> m(V?) would not be.  But under the new (subtyping) interpretation, we 
>> should treat them both as applicable, and V? is _more specific_ than 
>> OIbject, so we pick m(V?).
>>
>>
>>
>>> On Apr 16, 2019, at 10:30 AM, Srikanth 
>>> <srikanth.adayapalam at oracle.com> wrote:
>>>
>>> On a quick check, I see that on both directions, we have a compiler 
>>> inserted cast.
>>> As I understand, assignment of V to V? being a widening conversion, 
>>> the cast should go away while
>>> the other direction is still being debated.
>>>
>>> This should be straightforward.
>>>
>>> Srikanth
>>>
>>> On 16/04/19 7:50 PM, Brian Goetz wrote:
>>>> OK, thanks.  Hopefully the new rules will be simpler, as they lean 
>>>> more heavily on subtyping.
>>>>
>>>>
>>>>> On Apr 16, 2019, at 10:18 AM, Srikanth 
>>>>> <srikanth.adayapalam at oracle.com> wrote:
>>>>>
>>>>>
>>>>> This change set just introduces the new notation doing nothing new 
>>>>> about inserting casts.
>>>>> I will go through the mails discussing this and follow up on a 
>>>>> different change set.
>>>>>
>>>>> Thanks
>>>>> Srikanth
>>>>> On 16/04/19 7:32 PM, Brian Goetz wrote:
>>>>>>> This was a request for LW2 - no more boxing.
>>>>>> Right.  I was wondering whether we got there yet, or whether we’d 
>>>>>> just change the notation to start.
>>>>>>
>>>>>>> We asked for the subtype relationship for both values and for 
>>>>>>> arrays.
>>>>>> For arrays, the covariance rule: T <: U imples T[] <: U[] — 
>>>>>> should hold uniformly.  No need for special exceptions for value 
>>>>>> arrays.  Since
>>>>>>
>>>>>>      V <: Object
>>>>>> and
>>>>>>      V? <: Object
>>>>>>
>>>>>> then both V[] and V?[] are <: Object[].
>>>>>>
>>>>>>
>>>>>>
>>>>>>> For LW2 - we requested explicit checkcasts on attempts to narrow.
>>>>>>>
>>>>>>> Agreed that there are discussions about where this is all going 
>>>>>>> after LW2 before LW10.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Karen
>>>>>>>
>>>>>>>> On Apr 16, 2019, at 9:24 AM, Brian Goetz 
>>>>>>>> <brian.goetz at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Is the conversion from V to V? still considered a boxing 
>>>>>>>> conversion, or is it a widening conversion now?  The language 
>>>>>>>> we (currently think we) want is
>>>>>>>>
>>>>>>>>   V <: V?
>>>>>>>>
>>>>>>>> In the other direction, we’re still discussing whether the 
>>>>>>>> narrowing conversion is implicit or explicit.
>>>>>>>>
>>>>>>>>> On Apr 16, 2019, at 8:09 AM, Srikanth 
>>>>>>>>> <srikanth.adayapalam at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Notes:
>>>>>>>>>
>>>>>>>>>    - This is the initial commit for supporting V? notation as 
>>>>>>>>> an alternate for V.box
>>>>>>>>>    - The old .box and .val notation is not withdrawn yet and 
>>>>>>>>> can still be used, but we should really move over to the new 
>>>>>>>>> syntax as soon as possible.
>>>>>>>>>    - Existing javac tests have been replicated to use the V? 
>>>>>>>>> syntax.
>>>>>>>>>    - VBC migration related work is not done yet.
>>>>>>>>>    - One issue that showed up in the parser implementation is 
>>>>>>>>> the ambiguity at the point of seeing ?
>>>>>>>>>       in  v instanceof Type? exp: exp2; I have arranged for 
>>>>>>>>> this to be processed as a conditional rather
>>>>>>>>>       than as denoting nullability.
>>>>>>>>>    - On a long value type name the ? suffix does not really 
>>>>>>>>> stand out ATM, but I guess IDE colorcoding can address this 
>>>>>>>>> issue.
>>>>>>>>>    - There is one failing test in the langtools suite 
>>>>>>>>> (jdk/jshell/TypeNameTest.java) I will raise a follow up
>>>>>>>>>      ticket to address this.
>>>>>>>>>    - More testing is required and will be undertaken in the 
>>>>>>>>> coming weeks. I request/encourage testing by the interested 
>>>>>>>>> parties too.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Srikanth
>>>>>>>>>
>>>>>>>>> On 16/04/19 5:32 PM, srikanth.adayapalam at oracle.com wrote:
>>>>>>>>>> Changeset: bf52db1ad4ea
>>>>>>>>>> Author:    sadayapalam
>>>>>>>>>> Date:      2019-04-16 17:31 +0530
>>>>>>>>>> URL: 
>>>>>>>>>> http://hg.openjdk.java.net/valhalla/valhalla/rev/bf52db1ad4ea
>>>>>>>>>>
>>>>>>>>>> 8221545: [lworld] Preliminary support for alternate 
>>>>>>>>>> denotation of values and boxes
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java 
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java 
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java 
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java 
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java 
>>>>>>>>>>
>>>>>>>>>> ! 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/BogusIncompatibility.java
>>>>>>>>>> + 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/BoxValCastTest2.java 
>>>>>>>>>>
>>>>>>>>>> + 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/GenericsWithQuestion.java
>>>>>>>>>> + 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/GenericsWithQuestion.out
>>>>>>>>>> ! 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/InnerClassAttributeValuenessTest.java
>>>>>>>>>> + 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/IntercastTest2.java 
>>>>>>>>>>
>>>>>>>>>> + 
>>>>>>>>>> test/langtools/tools/javac/valhalla/lworld-values/LookupOnLoxTest2.java 
>>>>>>>>>>
>>>>>>>>>> ! test/langtools/tools/javac/valhalla/lworld-values/Point.java
>>>>>>>>>>
>