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

[Remi Forax]

There is also something fun.
You don't need to specialize for all primitive types but only one 32bits 
and one 64bits if the specializable code contains only bytecodes of the 
first 5 categories.

Rémi

On 07/28/2014 09:53 PM, Dan Smith wrote:
> FYI, I put together this table a few months ago when we were exploring 
> the idea of specializing instructions.  (I tried the with an inline 
> table, and the mailing list didn't like that, so I'm re-sending with a 
> URL.)
>
> http://cr.openjdk.java.net/~dlsmith/instructions.png 
> <http://cr.openjdk.java.net/%7Edlsmith/instructions.png>
>
> Each column represents an abstract "specialize load (etc.) for 
> variable i" instruction (encoded in the class file as the reference 
> version (aload, etc.) with an accompanying "asterisk" that provides 
> i).  The rows provide the specialization output for the given 
> specialization type.  The comparison and array instructions are 
> especially interesting.
>
> Note on byte widths: I've listed the max width of the specialized 
> instructions, and padded the others to match.  Exception: value type 
> instructions would require 2 extra bytes for a pointer to the type 
> name, barring some clever encoding tricks (except vnewarray, which 
> already has room for this).  If the t<i> instructions were literally 
> bytecodes, they would also need 1 extra byte (or more?) to encode the 
> type parameter index, 'i'.  If in the distant future we introduced 
> another row to this table, we would be constrained by the amount of 
> bytes we'd already reserved...
>
> Things I don't know much about that might change this analysis: 
> 'wide', 'fcmpg'.
>
> (Final note: it probably goes without saying, but there are other 
> things besides bytecodes that need to be specialized, too, and 
> eventually we'll want to come up with a comprehensive list of those 
> things.)
>
> —Dan
>
> On Jul 24, 2014, at 7:21 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto: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 
>>> <mailto: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
>>>>
>>>
>>
>