[lworld] Handling of missing ValueTypes attributes
karen.kinnear at oracle.com
Tue Jul 10 18:24:32 UTC 2018
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
(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 -
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.
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)
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.
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?
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.
-------------- next part --------------
An embedded message was scrubbed...
From: Frederic Parain <frederic.parain at oracle.com>
Subject: Re: RFR: Value types consistency checks
Date: Fri, 6 Jul 2018 16:26:47 -0400
-------------- next part --------------
> 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).
More information about the valhalla-dev