vgetfield complete removal

[Frederic Parain]

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