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

[Remi Forax]

On 07/24/2014 03:21 PM, Maurizio Cimadamore wrote:
> Hi Remi,
> thanks for the comments. This is an initial prototype to get things 
> going and unblock the work on the specializer. The current support 
> will be enough to compile simple classes such as Box (in Brian's 
> document).
>
> Said that, opcodes such as dup/pop can easily be added in the current 
> code by adding more 'cases' to the filtering switch.
>
> areturn is there - but it's generated in a different code path - see 
> Gen.visitReturn.
>
> For opcodes such as new and newarray, we need to have unerased 
> expression types being saved by javac somewhere, so that was a bit 
> beyond the scope of this patch.

new if different of anewarray, i don't think you can specialize new.
anewarray is equivalent to getfield, the syntax use an internal name 
instead of a descriptor which is an historical glitch in my opinion
but if you know how to specialize getfield, you know how to specialize 
anewarray.

>
> Regarging comparisons - the first issue is that  type-checking support 
> for comparisons involving 'any' type-variable is not there yet - i.e. 
> the compiler will reject it as of now. Once that's allowed, you will 
> be able to compare T with T but not T with int (similarly as you 
> cannot compare an ordinary type-variable with a string). In other 
> words, I don't believe equals() will ever be generated - i.e. the 
> compiler will always use if_acmpeq and the likes, which will be 
> tagged, eventually, in the bytecode.

I was thinking about the opposite,
<any T> void m(T t1, t t2) {
   return t1.equals(t2);
}

does this code should use if_icmpeq if T is specialized with T=int.

>
> Maurizio

Rémi

>
> On 24/07/14 13:25, Remi Forax wrote:
>> Hi Maurizio,
>> I think you have miss several opcodes that also need to be marked as 
>> any,
>>   anewarray, areturn and i think dup, dup_x1, dup_x2  and pop
>> (I suppose than Object.equals will be used instead of if_acmpeq, 
>> if_acmpne)
>>
>> Maybe you want to treat anewarray like opcodes getfield/invoke* but
>> in that case, either you need invokedynamic or a new bytecode ?
>>
>> cheers,
>> Rémi
>>
>> On 07/24/2014 01:26 PM, maurizio.cimadamore at oracle.com wrote:
>>> Changeset: bb57e20a33a4
>>> Author:    mcimadamore
>>> Date:      2014-07-24 12:22 +0100
>>> URL: 
>>> http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/bb57e20a33a4
>>>
>>> Add support for tracking 'any'-related opcodes
>>> *) Overhauled Items hierarchy (now field/methods have their own 
>>> classes)
>>> *) Add AnyItem to model a bytecode item associated with 'any' variables
>>> *) Add new BytecodeMapping attribute to map 'any'-related opcodes 
>>> back to the original (unerased) signature
>>>
>>> ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
>>> ! src/share/classes/com/sun/tools/javac/jvm/Code.java
>>> ! src/share/classes/com/sun/tools/javac/jvm/Gen.java
>>> ! src/share/classes/com/sun/tools/javac/jvm/Items.java
>>> ! src/share/classes/com/sun/tools/javac/util/Names.java
>>>
>>
>