review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010

John Rose john.r.rose at oracle.com
Tue Sep 14 19:55:26 PDT 2010


On Sep 14, 2010, at 2:51 AM, Christian Thalinger wrote:

> On Mon, 2010-09-13 at 13:17 -0700, John Rose wrote:
>> Note:  I just split the MethodApply part of this bug as its own bug; the new number is 6984311.
>> 
>> -- John
>> 
>> On Sep 12, 2010, at 3:11 AM, John Rose wrote:
>> 
>>> 6981777: implement JSR 292 EG adjustments from summer 2010
>>> Summary: Introduce one more constant pool type, CONSTANT_MethodApply.
>>> 
>>> This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods:
>>> http://cr.openjdk.java.net/~jrose/6981777/webrev.00
>> 
> 
> agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java
> src/share/vm/ci/ciObjectFactory.cpp:
> src/share/vm/ci/ciObjectFactory.hpp:
> src/share/vm/classfile/classFileParser.cpp:
> src/share/vm/classfile/systemDictionary.cpp:
> src/share/vm/memory/universe.hpp:
> src/share/vm/oops/constantPoolKlass.cp:
> src/share/vm/prims/jvm.h:
> src/share/vm/prims/methodComparator.hpp:
> src/share/vm/utilities/constantTag.cpp:
> src/share/vm/utilities/constantTag.hpp:
> 
> Copyright year update missing.

Thanks.  I found a couple more, too.

> src/share/vm/prims/jvm.h:
> agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java:
> 
>     JVM_CONSTANT_MethodHandle           = 15,  // JSR 292
>     JVM_CONSTANT_MethodType             = 16,  // JSR 292
> +    JVM_CONSTANT_MethodApply            = 18,  // JSR 292
>     JVM_CONSTANT_InvokeDynamic          = 17  // JSR 292
> 
> It's just a nit, but could you swap the numbers of the last two?

I agree it's annoying, but I'd rather not change a pre-existing number.  If we change CONSTANT_InvokeDynamic it might pull the rug out from under an early adopter, although that constant itself is fairly new.

I'll put the constant declarations in numerical order, at least.

> That would require to revert this change:
> src/share/vm/utilities/constantTag.hpp:
> 
> -           (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_InvokeDynamic) ||
> +           (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_MethodApply) ||

> 
> src/cpu/x86/vm/templateTable_x86_32.cpp:
> 
> Why do we need this change only on x86_32?

Because I hadn't ported it yet.  I just did.  While I was at it I ported to sparc also.  And I also rolled in the sparc code for the previous change (invokeGeneric).

Here's the update:

http://cr.openjdk.java.net/~jrose/6984311/webrev.01/

Note:  I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool.  The EG is discussing both options.

-- John

> Otherwise looks good.
> 
> -- Christian
> 



More information about the hotspot-compiler-dev mailing list