Request for review (S): 6817525: turn on method handle functionality by default for JSR 292

Christian Thalinger christian.thalinger at
Tue Mar 29 11:52:04 PDT 2011

On Mar 29, 2011, at 8:47 PM, Vladimir Kozlov wrote:
> It should be product flag from now on.

I agree.  John wrote in an earlier email:

"EnableInvokeDynamic and related switches may be useful for diagnostic testing, for root cause analysis.  And they are needed to differentiate behavior of 1.6 from 1.7.  But they are probably not useful as full product switches.  Unless there's a reason against it, we should categorize them as diagnostic switches."

But I seems there is a reason against it.

-- Christian

> Vladimir
> Christian Thalinger wrote:
>> On Mar 29, 2011, at 6:48 PM, Tom Rodriguez wrote:
>>> Additionally all our existing testing is turning it on using -XX:+EnableInvokeDynamic so unless we want to flag a flag day we should stick with that.  I assume that EnableMethodHandles and AnonymousClasses aren't explicitly turned on as part of any of our testing?  Otherwise we might want to accept them and convert them into EnableInvokeDynamic, at least for a little while to ease the transition.
>> I changed it to EnableInvokeDynamic and kept the other options which turn on EnableInvokeDynamic if true.  But if we change EnableInvokeDynamic from an experimental to a diagnostic flag we will run into trouble with tests anyway:
>> $ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic
>> Unrecognized VM option '+EnableInvokeDynamic'
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> -- Christian
>>> tom
>>> 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.
>>>> Paul
>>>> 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.
>>>>> -John
>>>>> 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. 
>>>>>> Vladimir 
>>>>>> 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 mailing list