vgetfield complete removal

[Frederic Parain]

Thank you Karen and Maurizio for the reviews.

Fred

> On Aug 9, 2017, at 09:49, Karen Kinnear <KAREN.KINNEAR at ORACLE.COM> wrote:
> 
> 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
>> 
>> 
>