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

[Remi Forax]

Dan,
nice table, better than the one I've on my backboard :)
in your table, the nops for padding are sometimes inserted before the 
instruction and sometimes after the instruction,
I think it should be always inserted after the instruction.

About the array instructions (the t<i> instructions), I agree that they 
should be encoded the same way than a getfield or a method call.

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