review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010
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:
> Copyright year update missing.
Thanks. I found a couple more, too.
> 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:
> - (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_InvokeDynamic) ||
> + (tag >= JVM_CONSTANT_MethodHandle && tag <= JVM_CONSTANT_MethodApply) ||
> 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:
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.
> Otherwise looks good.
> -- Christian
More information about the hotspot-compiler-dev