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

[Maurizio Cimadamore]

On 24/07/14 17:19, Remi Forax wrote:
>
> 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.
I said new - because there will need to be something if you do

new ArrayList<int>

in order to point back at the unerased info. This will become something 
else in the long run, but for now tagging 'new' will make sure that the 
specializer will have a chance to rewrite the name of the class to be 
instantiated.
>
>>
>> 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.

The code above doesn't compile. It doesn't make sense (at least for now) 
to speak about members of an 'any' type-variable, so there's no equals in T.

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