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

[Maurizio Cimadamore]

On 28/07/14 17:26, Remi Forax wrote:
>
> 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.
That is what I meant by 'inference' (sorry for the loose terminology here)
>
> 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.
Yep - I agree that's the case.

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