[lworld] Handling of missing ValueTypes attributes

[Ioi Lam]

On 7/10/18 11:24 AM, Karen Kinnear wrote:
> Let me clarify the LW1 proposal. This model is designed to NOT take into account migration of value-based classes, which we will revisit
> much farther downstream.
>
> For LW1 - the goal is to fail with an ICCE if there are inconsistencies with value type expectations. The question is when do we catch
> the problem and fail, and do we allow field access and method invocation when the information is inaccurate.
>
> Ioi - here is the proposal
> http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf
> (As John pointed out in another email - I should update it to describe the ValueTypes attribute - for now see the not-yet-out latest JVMS draft -
>
> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4e.pdf
>
> For local methods there are two parts:
> 1) if a type in a descriptor is in the ValueTypes attribute, we will eagerly load it at preparation time. If it is not a value type, we will throw ICCE.
> 2) if a type in a descriptor is NOT in the ValueTypes attribute: see *5 Method Invocation: VT Point NOT in ValueTypes attribute in the Consistency
> Checking link. Extracted here - let me know if this does not make sense:
>
> Point is a value type.
> ClassA contains method m1(Point point). Point is NOT in Class A’s ValueTypes attribute. I think this matches Ioi’s and Tobias’ examples.
>
> case 1: method overriding
> ClassA’s method m1 overrides ClassZZ’s method m1, and m1 is in ClassZZ’s ValueTypes attribute. Preparation of ClassA will fail with ICCE when creating the vtable.
> ClassD extends ClassA, ClassD’s method m1 overrides ClassA’s m1 and m1 is in ClassD’s ValueTypes attribute. Preparation of ClassD will fail with ICCE when creating the vtable due to the mismatch. Note ClassA keeps going - I don’t know of a way to bubble up the failure since ClassA may be in use.
>
> case 2:
> ClassB has Point in ValueTypes attribute and invokes ClassA.m1.
>     - ClassB can successfully create an instance of Point
>     - at method resolution time, caller-callee consistency check will throw ICCE, so ClassB can not invoke ClassA.m1
> (Tobias - I think this is your last paragraph “Now another compiled method)
>
> case 3:
> ClassC does NOT have Point in ValueTypes attribute and invokes ClassA.m1
>     ClassC is able to invoke ClassA - caller/callee check passed consistency (without checking reality)
>     ClassC can pass a null Point
>     
> So - from a compiler perspective - only classes that share the same ValueTypes attribute information about Point can call ClassA.m1.
Thanks Karen for the explanation. I think it will simplify my patch for 
JDK-8206140 [lworld] Move return value null checks into the callee.

If I understand correctly, this means that when we try to resolve a 
ClassRef, FieldRef, MethodRef, ..., in the constant pool, and there's a 
cross-class mismatch of ValueType, the constant pool entry will fail to 
resolve, and an ICCE will be thrown.

This means the compiler should never see a mismatched cross-class 
reference. For example,

class ClassB {
     void foo(Point p) {
          ClassA.m1(p);  // ....., invokestatic MethodRef #4 = 
ClassA.m1:"(LPoint;)V"
     }
}

When foo is compiled, the compiler will see that the constant pool entry 
MethodRef #4 is unresolved. Thus, the compiler will generate an uncommon 
trap and let the interpreter handle it. The interpreter will try to 
resolve #4 again, resulting in an ICCE.

BTW, value-types-consistency-checking-details.pdf doesn't mention 
MethodHandle and Reflection explicitly. However, I assume that the same 
set of rules applies as well?

Thanks
- Ioi

>  From an execution perspective, we would like to ensure that neither ClassC nor ClassA can get their hands on an instance of Point, so
> we are only passing null here. Tried to close all of these holes - could use review. Note to John - consistency checking for array elements
> relative to ValueTypes attribute is part of closing this hole, i.e. ensuring that a class that has the wrong information about whether a type
> is a value type can not get their hands on an instance of that value type.
>
> Does this make sense for LW1?
>
> thanks,
> Karen
>
> p.s. Frederic checked in round 1 of the consistency checking - but did not get round 2 in before he left for vacation. He is out this
> week and the next. I attached his patch out for review if you want to use it to test with to see if that helps the compiler. He will be back I
> believe the 23rd. I will check with Harold on Frederic’s verifier question - we may want to push this (without perhaps the new test) before
> he gets back so you can use it.
>
> Note - John asked for some refactoring - given how tight the time is before EA and the vacation schedule - that will be a postlw1 rfe.
>
>
>
>
>
>
>
>> On Jul 10, 2018, at 8:22 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>> Hi John,
>>
>> On 10.07.2018 02:08, John Rose wrote:
>>> On Jul 9, 2018, at 3:44 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>>> In that case, I think the program's output should be the same as if the ValueTypes attribute had been present, although performance may differ (slower, more heap allocations, etc).
>>>>
>>>> Is this understanding correct?
>>> Yes, that is correct.  This model is intended to make it easier for old-school classfiles
>>> to link to old types which have (over time) been upgraded to value types.
>> How do we then handle the following scenario?
>>
>> We have a method m1(MyValue vt) in a class that has no value types attribute set although MyValue is
>> a value type. Once the calling convention for that method is determined (i.e. at adapter creation),
>> we therefore don't know that MyValue is a value type and as a result, m1 will expect vt to be passed
>> as oop.
>>
>> Now another compiled method m2 that calls compiled m1 might be well aware that vt is a value type
>> but has no way to know that m1 does *not* expect vt to be passed as fields (especially if the call
>> is virtual).
>>
>> Thanks,
>> Tobias