vgetfield complete removal

[Maurizio Cimadamore]

Thanks for the explanations.

This looks good to me.

Maurizio


On 08/08/17 22:12, Frederic Parain wrote:
> 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
>>>
>>>