Request for review (S): 6817525: turn on method handle functionality by default for JSR 292
tom.rodriguez at oracle.com
Tue Mar 29 09:39:41 PDT 2011
I don't think there's much to recommend EnableDynamic over just sticking with EnableInvokeDynamic. It's already well known to anyone doing JSR292 hacking and no one else should really ever know or care about its existence.
On Mar 29, 2011, at 9:33 AM, Paul Hohensee wrote:
> I'd say the same: EnableJSR292 is a JCP process memento. If, as Tom says,
> you intend to enable all these features as a set, then I'd generify EnableInvokeDynamic
> by replacing it with, say, EnableDynamic. The latter is non-specific enough to
> cover the field and isn't tied to a specific JSR.
> On 3/29/11 12:12 PM, John Pampuch wrote:
>> I think I agree with Vladimir. The name JSR-292 is an anomaly of the process, and doesn't really communicate much. I don't think we generally use the JSR ID for similar choices elsewhere either.
>> On 3/29/11 8:58 AM, Vladimir Kozlov wrote:
>>> I would prefer the old EnableInvokeDynamic which is more informative I think. Otherwise looks good.
>>> Christian Thalinger wrote:
>>>> On Mar 28, 2011, at 11:14 PM, John Rose wrote:
>>>>> On Mar 28, 2011, at 12:58 PM, Tom Rodriguez wrote:
>>>>>> Why do we need the related switches as separate flags at all? EnableInvokeDynamic is required for 7 and the others are all implied by EnableInvokeDynamic. I don't see how they can be turned on or off independently in a meaningful way. I think it's more confusing having all these separate subflags.
>>>>> Merging them up to a single flag would be OK with me. (And since it's diagnostic, I don't care too much what the name is.)
>>>> The obvious name is EnableJSR292. The change is now much bigger but almost all changes are trivial renames:
>>>> I did a lot of testing with JRuby tests today and except a couple of (expected) hiccups it looks good.
>>>> -- Christian
More information about the hotspot-dev