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

[Dan Smith]

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

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