hg: valhalla/valhalla/langtools: Add support for tracking 'any'-related opcodes
maurizio.cimadamore at oracle.com
Mon Jul 28 23:40:21 UTC 2014
This looks promising - are you envisioning some kind of 'inference' in
the VM in order to figure out the 'width' of the v* opcodes? That might
be non-trivial as it would probably mean propagate type info from the
local var table attribute? An alternative perhaps could be to accept an
extra operand containing the 'width' (i.e. 1 for int, 2 for
double/long, n for value types).
On 28/07/14 16:26, John Rose wrote:
> On Jul 28, 2014, at 4:09 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> yes, if you do local var slot renaming for value type when parsing the bytecode,
>> you can use the same mechanism for double.
> Here is a concrete suggestion, to get rid of double slots completely in the setting of value types:
> Deprecate and remove [ld][a]?load* and [ld][a]?store* opcodes.
> In generated bytecodes, replace them by the corresponding v* opcodes (which would apply to long and double primitive values, as well as non-primitive, non-reference values).
> A few other opcodes (d2i, etc.) are kept as-is, but the slot-pair semantics are removed for them also.
> Later, repurpose those opcode points for other things. (This will free the d* or l* series of instructions for later use.)
> For compatibility, old class file versions would continue to use slot-pairs (and will not recognize v* bytecodes).
> New class file versions would refuse (at least some of) the [dl]* bytecodes.
> — John
More information about the valhalla-dev