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

[Remi Forax]

On 07/24/2014 03:56 PM, Brian Goetz wrote:
> I don’t think that polymorphic byte codes (dup, getfield, etc) need to be annotated; this attribute tells us which bytecodes have to be rewritten for specialization.  Since dup is valid on all types, everything should just come out in the wash.

The problem of dup, is that int and double don't take the same space on 
stack, so if there is an any on top of the stack,
after specialization it can be transformed either to a dup or to a dup2 
depending if it's a specialization to int or to double.

Also, I've forgotten 'swap' in my list, and there is no swap2.

For getfield/method call, if you don't annotate them, you need to 
propagate the types of the values on the stack and
the type of the local variables. If you propagate the type of the local 
variable, you don't need to annotate 'aload 2'
because you already know that the local variable at slot 2 is any.

So either you annotate aload and getfield, or you don't annotate any of 
them.

Rémi

>
> On Jul 24, 2014, at 9:21 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> 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.
>>
>> 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.
>>
>> Maurizio
>>
>> 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
>>>>