RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

[Claes Redestad]

Thanks Vladimir!

/Claes

On 2015-12-09 13:10, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 12/2/15 4:24 PM, Claes Redestad wrote:
>>
>> On 2015-11-18 23:26, Aleksey Shipilev wrote:
>>> By the way, I see there is a cleaner way to implement emitIconstInsn,
>>> see java.lang.invoke.TypeConvertingMethodAdapter.iconst:
>>>
>>>      void iconst(final int cst) {
>>>          if (cst >= -1 && cst <= 5) {
>>>              mv.visitInsn(Opcodes.ICONST_0 + cst);
>>>          } else if (cst >= Byte.MIN_VALUE && cst <= Byte.MAX_VALUE) {
>>>              mv.visitIntInsn(Opcodes.BIPUSH, cst);
>>>          } else if (cst >= Short.MIN_VALUE && cst <= Short.MAX_VALUE) {
>>>              mv.visitIntInsn(Opcodes.SIPUSH, cst);
>>>          } else {
>>>              mv.visitLdcInsn(cst);
>>>          }
>>>      }
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/aa9e8b3916ae/src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java#l285 
>>>
>>>
>>>
>>
>> Nice catch.
>>
>> Picking up this tiny improvement again, I realized there are a few other
>> bytecode minifying tricks we could consider while we're at it:
>>
>> http://cr.openjdk.java.net/~redestad/8143127/webrev.02/
>>
>> It would probably make sense to move emitConst to
>> TypeConvertingMethodAdapter and use that in place a raw MethodVisitor -
>> removing some code - but there might be some reasons not to
>> (bootstrapping?). For this improvement I opt to keep the changes
>> contained inside InvokerBytecodeGenerator. unless someone insists.
>>
>> /Claes