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

Mon Jul 28 21:39:57 UTC 2014

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:44 PM, Dan Smith wrote:
> FYI, I put together this table a few months ago when we were exploring 
> the idea of specializing instructions.  (Don't know if the mailing 
> list preserves formatting; if not, let me know and I'll try to 
> reproduce the table as text-only.)
>
> 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.
>
>
> 	
> *t<i>load*
> 	
> *t<i>_load_<n>*
> 	
> *t<i>store*
> 	
> *t<i>store_<n>*
> 	
> *t<i>return*
> 	
> *if_t<i>cmpeq*
> 	
> *if_t<i>cmpneq*
> 	
> *t<i>newarray*
> 	
> *t<i>aload*
> 	
> *t<i>astore*
>
> 	
> *2 bytes*
> 	
> *1 bytes*
> 	
> *2 bytes*
> 	
> *1 byte*
> 	
> *1 byte*
> 	
> *4 bytes*
> 	
> *4 bytes*
> 	
> *3 bytes*
> 	
> *1 byte*
> 	
> *1 byte*
> *reference*
> 	
> *aload*
> 	
> *aload_<n>*
> 	
> *astore*
> 	
> *astore_<n>*
> 	
> *areturn*
> 	
> *nop*
> *if_acmpeq*
> 	
> *nop*
> *if_acmpneq*
> 	
> *anewarray*
> 	
> *aaload*
> 	
> *aastore*
> *value*
> 	
> *vload*
> 	
> *vload_<n>*
> 	
> *vstore*
> 	
> *vstore_<n>*
> 	
> *vreturn*
> 	
> *vcmp*
> *ifeq*
> 	
> *vcmp*
> *ifeq*
> 	
> *vnewarray*
> 	
> *vaload*
> 	
> *vastore*
> *boolean*
> 	
> *iload*
> 	
> *iload_<n>*
> 	
> *istore*
> 	
> *istore_<n>*
> 	
> *ireturn*
> 	
> *nop*
> *if_icmpeq*
> 	
> *nop*
> *if_icmpneq*
> 	
> *newarray 4*
> *nop*
> 	
> *baload*
> 	
> *bastore*
> *char*
> 	
> *iload*
> 	
> *iload_<n>*
> 	
> *istore*
> 	
> *istore_<n>*
> 	
> *ireturn*
> 	
> *nop*
> *if_icmpeq*
> 	
> *nop*
> *if_icmpneq*
> 	
> *newarray 5*
> *nop*
> 	
> *caload*
> 	
> *castore*
> *byte*
> 	
> *iload*
> 	
> *iload_<n>*
> 	
> *istore*
> 	
> *istore_<n>*
> 	
> *ireturn*
> 	
> *nop*
> *if_icmpeq*
> 	
> *nop*
> *if_icmpneq*
> 	
> *newarray 8*
> *nop*
> 	
> *baload*
> 	
> *bastore*
> *short*
> 	
> *iload*
> 	
> *iload_<n>*
> 	
> *istore*
> 	
> *istore_<n>*
> 	
> *ireturn*
> 	
> *nop*
> *if_icmpeq*
> 	
> *nop*
> *if_icmpneq*
> 	
> *newarray 9*
> *nop*
> 	
> *saload*
> 	
> *sastore*
> *int*
> 	
> *iload*
> 	
> *iload_<n>*
> 	
> *istore*
> 	
> *istore_<n>*
> 	
> *ireturn*
> 	
> *nop*
> *if_icmpeq*
> 	
> *nop*
> *if_icmpneq*
> 	
> *newarray 10*
> *nop*
> 	
> *iaload*
> 	
> *iastore*
> *long*
> 	
> *lload*
> 	
> *lload_<n>*
> 	
> *lstore*
> 	
> *lstore_<n>*
> 	
> *lreturn*
> 	
> *lcmp*
> *ifeq*
> 	
> *lcmp*
> *ifneq*
> 	
> *newarray 11*
> *nop*
> 	
> *laload*
> 	
> *lastore*
> *float*
> 	
> *fload*
> 	
> *fload_<n>*
> 	
> *fstore*
> 	
> *fstore_<n>*
> 	
> *freturn*
> 	
> *fcmpl*
> *ifeq*
> 	
> *fcmpl*
> *ifneq*
> 	
> *newarray 6*
> *nop*
> 	
> *faload*
> 	
> *fastore*
> *double*
> 	
> *dload*
> 	
> *dload_<n>*
> 	
> *dstore*
> 	
> *dstore_<n>*
> 	
> *dreturn*
> 	
> *dcmpl*
> *ifeq*
> 	
> *dcmpl*
> *ifneq*
> 	
> *newarray 7*
> *nop*
> 	
> *daload*
> 	
> *dastore*
> *
> *
>
>
> 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
>>>>
>>>
>>
>