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

[David Chase]

On Jul 28, 2014, at 8:20 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Jul 28, 2014, at 4:40 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 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).
> 
> Which opcode would have an ambiguous input?  Can't you always tell whether it is I, J, or some specific value type?
> 
> ...Or any other type:  Seems to me that, for correctness, we only need v* and none of the [ailfd]*, if we do very simple forward-only inference, like that supported by FrameMaps already.

Do you have any plans to get rid of the invokevirtual/invokeinterface distinction?
Is it ever the case that both are legal but yield different results?
I recall that the Fortress specializer had its own stupid little special case
for dealing with this for different flavors of T’s replacement.

David