hg: valhalla/valhalla: 8222634: [lworld] Javac sometimes emits incorrect ('Q') descriptors for fields.

[Karen Kinnear]

Srikanth,

Filed JDK-8222663.

So I thought Brian had asked for a change from $makeValue$ to <init> — I don’t have the specifics -
do you need a different rfe for that?

thanks,
Karen
  
> On Apr 17, 2019, at 11:30 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> Hi Karen,
> 
> Yes, please, raise a ticket ideally with a snippet that shows the problem and the expected behavior in terms of generated code.
> 
> Thanks!
> Srikanth
> 
> On 17/04/19 8:55 PM, Karen Kinnear wrote:
>> Srikanth,
>> 
>> Many thanks for the quick turnaround on fixes. Your timing helps a great deal as we try to get an LW2 EA
>> ready since you are at the start of the chain.
>> 
>> So in addition to the ValueType?[42] array syntax you are working on, we had one more issue with
>> the new syntax update:
>> 
>> “withfield” handling:
>> Old __Withfield syntax supported the model that it could be used in any nestmates of the declaring class,
>> and would explicitly generate just the single bytecode “withfield”.
>> 
>> The updated syntax “MyValue1.f1 = Foo;”
>>   appears to be using different restrictions:
>>   javac appears to be restricting it to constructors which convert to factories
>>   and therefore is generating defaultvalue followed by with fields.
>> 
>> The intent was to have the new syntax also just generate a single “withfield” bytecode with the
>> nestmate restrictions.
>> 
>> As Frederic reminded us, the use model use case is iterators, e.g. for a Cursor inlined class.
>> 
>> Does this make sense to you? Do you need me to file a JBS for this?
>> 
>> thanks,
>> Karen
>> 
>>> On Apr 17, 2019, at 10:09 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> 
>>> Great.  Note that null-default is for L20, not L10, so perhaps we should work that in a dependent branch?
>>> 
>>>> On Apr 17, 2019, at 10:02 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 17/04/19 6:43 PM, Brian Goetz wrote:
>>>>>>> (1) Compile time null assignment to values should be tolerated (?)
>>>>>>> (2) Compiler does not tolerate the following:
>>>>>>> MyValue1?[] vBoxArray = new MyValue1?[42];
>>>>>> On (1) can I get a quick confirmation that this is what we want ? I did see some discussion regarding javac not proactively catching these and letting the VM report an NPE. But I seem to have missed the rationale behind that decision against failing early.
>>>>> On (1), I think this should be done on the basis of value set inclusion.  For reference types, null-default value types, and the nullable-projection of zero-default value types (V?), null is a member of the value set; for primitives, and for zero-default value types, it is not.  I think the compiler should not allow assignment of a value that is not a member of the value set.
>>>> Perfect. I must have misread a private communication from one of the contributors that ATM I am unable to locate, but your outline clarifies the questions I had.
>>>> 
>>>> javac does not yet have a notion of null default value types. Other than that the tip behavior should match what describe above. I have half a dozen smallish tasks to wrap the various loose ends and also test the V? implementation more and after that I will start on the null default value types.
>>>> 
>>>> Thanks
>>>> Srikanth
>>>>> We need better terminology….I said value and null too many times in the above paragraph.
>