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

[Maurizio Cimadamore]

On 24/07/14 18:00, Remi Forax wrote:
>
> On 07/24/2014 06:35 PM, Maurizio Cimadamore wrote:
>>
>> 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.
>
> I see, but this code is not specializable.
> In my opinion, new ArrayList<int> should be rewritten to use 
> invokedynamic, here is why.
>
> I think the specializer as you call it should work at runtime, 
> otherwise we will run in exactly the same trouble we have with inner 
> classes,
> binary compatibility being the biggest issue.
> So there is an issue if you generate ArrayList<int> at runtime, it 
> doesn't exit at compile time :)
> so you can not have a name to insert in the bytecode.
>
> For me, ArrayList<int> or ArrayList<double> should be erased as Object 
> (exactly like the supertype of int[] and double[] is Object),
> and the type argument should be sent as a bootstrap argument to a 
> special invokedynamic.
>
> basically
>   new ArrayList<int>
> can be trasformed to
>   invokedynamic <init> ()Ljava/lang/Object;  [ int.class ]
>
> likewise, any method call on ArrayList<int> should be an invokedynamic.
>
> With that, at runtime, in the bootstrap method, you can ask the 
> specializer to generate specialized class only when needed,
> i.e the first time a constructor is called.
In time, an approach similar to the one you describe will be used - in 
the meantime, we'd like to get more experience with these features by 
using an offline specializer that goes through the bytecode and spits 
specialized versions of the classfiles.
>
>
>>>
>>>>
>>>> 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.
>
> so practically there will be at least two codes by method, the one 
> that takes an Object because you can do equals on it
> and the one that takes any that will use ==.
That's the status of the current (very early) prototype. Nothing is set 
in stone at this point - but it seems like a stable design choice.

Maurizio
>
>>
>> Maurizio
>
> Rémi
>