vgetfield complete removal

[Maurizio Cimadamore]

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
>
>