vgetfield complete removal

[Karen Kinnear]

Frederic,

Code looks good. 

Thank you for the explanation. Creative approach.
So now we actually get quickening for getfield regardless of value type or reference -
that is a plus.

Thank you for testing Linux and Mac.
Karen

> On Aug 8, 2017, at 3:45 PM, Frederic Parain <frederic.parain at oracle.com> 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
> 
>