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

[Remi Forax]

On 07/24/2014 07:33 PM, Maurizio Cimadamore wrote:
>
> 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.

while I understand that you want to find the best class file format and 
how to verify it, how from that to specialize a class, etc,
i think that wrestling with the Java classloading monster is as 
important and should be done sooner than later.

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

I'm not saying it's bad, i think it's better than what i was thinking :)

>
> Maurizio

Rémi