hg: valhalla/valhalla/langtools: Add support for tracking 'any'-related opcodes

[Remi Forax]

On 07/29/2014 01:40 AM, Maurizio Cimadamore wrote:
> 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).
>
> Maurizio

Hi Maurizio,
you don't need a real inference for long/double etc or value type 
because there is no subtyping rule,
you just have to calculate the type of all the local variables and the 
stack slots.

The verifier must already do that in order to verify stackmap attribute 
(that are mandated since 1.7),
so during the verification, we alreadly have all the information, you 
just need to tag the opcode
with the type information.
The drawback is that it will make the verifier code a little more 
complex so more prone to error
that may lead to a security issue.

Rémi

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