vgetfield complete removal

[Frederic Parain]

I intentionally avoid calling the new type utos, because its meaning is different.
Here’s, we just need a way to factorize some code based on the properties of
our implementation. U-types (and their associated utos TosState) will have a
different semantic, allowing a given bytecode to executed on either a L-type
or a Q-type. Note that at the implementation level, it doesn’t impose that the
code is shared between L-types and Q-types.

There’s no issue with flattened fields, because there’s no quickening when the
field being read is a value type. With optional flattening, it will be possible to
implement quickening for non-flattened fields. But the case of flattened fields
is so complex, that I would not look at any quickening solution before the very
end of the project.

Note that nesting (flattening value types inside other value types) is already
supported in Valhalla. But it is transparent for the interpreter which only sees
one level. If object O has a value field A which itself has a value field B, when
the value field A is read from O, the interpreter doesn’t even know there’s a
value B inside A, it only sees a ‘container’ with type A.

Fred


> On Aug 8, 2017, at 17:02, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Cool
> 
> can we rename ptos to 'utos', to echo John's U-types - since that's what this is, after all?
> 
> Also, would this new framework work if we decide to handle value fields flattening inside other values? I think quickening might fail there (there's no quickened case for when the field type is Q right?)
> 
> Maurizio
> 
> 
> On 08/08/17 20:45, Frederic Parain wrote:
>> Greetings,
>> 
>> Here’s a changeset to remove all remaining references to vgetfield in HotSpot code.
>> 
>> http://cr.openjdk.java.net/~fparain/vgetfield_removal/webrev.00/index.html
>> 
>> The issues with merging getfield and vgetfield semantic were due to the top-of-stack
>> optimization (TosCache). TosCache allows the interpreter to sometime cache the
>> argument on the top of the stack in a register to avoid too much data movements
>> between the stack and the registers. The template for the getfield bytecode in the
>> interpreter is not using the TosCache (because the type returned by the bytecode
>> is not known before the first execution, and because the template is shared
>> between getfield and getstatic). So it works well for both objects and value types.
>> But after the first execution, the getfield byte code is rewritten into a ‘quick’ version,
>> and this one is using the TosCache for both the input and the output TosState.
>> This is where troubles show up: the expected type of the TosCache for the
>> quick getfield bytecodes is 'atos', which means an object reference is expected.
>> So the quicken bytecodes cannot work as-is on value types.
>> 
>> The TosCache is a fundamental piece of the interpreter, to avoid dynamic checks
>> on the TosCache, the whole dispatch mechanism between bytecodes is based on
>> TosState, and any inconsistency in the TosState would lead to an error message
>> about an invalid bytecode sequence.
>> 
>> From the interpreter point of view, objects and values are very similar, they are in
>> fact structurally equals (but their semantic is different). It would have been a shame
>> not being able to share bytecodes templates between objects and values. Quick
>> bytecodes are consuming a lot of bytecode values (there’s one quick bytecode per
>> return type).
>> 
>> the proposed changeset extends the template framework in the interpreter so now,
>> it is possible to define a template that can be used either with an object reference or
>> a value type in the TosCache. When dispatch tables are generated, both the atos
>> and the qtos entries for a quick bytecode are pointing to the same entry point in
>> the bytecode code snippet (so not only the template is shared, but also the code
>> generated from the template).
>> 
>> With this solution, getfield now fully supports both objects and values, and quickening
>> is now enabled when accessing primitive or reference fields of a value type.
>> 
>> The changeset has been tested with hotspot_valhalla and idk_valhalla_mvt test sets
>> on Mac and Linux, with fastdebug and product builds. It also passed a JPRT run.
>> 
>> Thank you,
>> 
>> Fred
>> 
>> 
>