Open code review for 8061999 Enhance VM option parsing to allow options to be specified
Dmitry Dmitriev
dmitry.dmitriev at oracle.com
Wed Jul 8 20:29:58 UTC 2015
Hello Karen,
On 08.07.2015 22:26, Karen Kinnear wrote:
> David,
>
> It is true that this option will not handle options that are targeted at the java
> launcher. And we should make that very clear in documentation - perhaps even spelling
> out which options are handled by the java launcher. Worth double-checking that
> with Kumar.
>
> There is another rfe going in for the launcher itself - which is JDK-8027634.
> That will cover options to the java launcher as well as to the vm and jdk via @argfiles, they same
> way apparently javac handles long command-lines today.
>
> Unfortunately that option only works for the specific launchers that support it.
> For folks who embed the jvm in their own applications, e.g. other language users,
> the new vm option allows them to pass in arguments to the jvm (and then up to the jdk)
> which the java launcher changes doesn't make possible.
>
> It might make sense as we figure out how to document this, to document the java
> launcher @argfiles as the usual approach for customers running java.
>
> And to document the new VM option explicitly for those who have their own launchers
> and call JNI_CreateJavaVM?
>
> Ron & Dmitry,
>
> A couple of test requests (you may already have these, I didn't see a code review out for 8073331)
> 1) tests with a jni launcher that calls JNI_CreateJavaVM
No, I don't have such test, because I don't think from that point of
view. I will think about that.
> 2) is there a maximum length to the options read in from the file?
The current implemented limitations are following: only one VM option
file can be specified, maximum size of the file is 1024 bytes, up to 64
VM options
>
> Also - Dmitry - can you please share your tests for this option with Henry Jen - he may want to modify them
> for tests for the java @argfiles.
>
> And we'll want to test the two new options together :-)
Yes, sure. I will contact with Henry and share tests.
Thanks,
Dmitry
>
> thanks,
> Karen
>
> On Jun 29, 2015, at 9:02 PM, David Holmes wrote:
>
>> On 27/06/2015 4:04 AM, Daniel D. Daugherty wrote:
>>> On 6/26/15 12:02 AM, David Holmes wrote:
>>>> On 26/06/2015 2:49 AM, Daniel D. Daugherty wrote:
>>>>> On 6/25/15 12:52 AM, David Holmes wrote:
>>>>>> On 25/06/2015 4:38 PM, Dmitry Dmitriev wrote:
>>>>>>> Hello David,
>>>>>>>
>>>>>>> I mean that we can define "-Dmy.property=value" inside VM Option file.
>>>>>> Okay - that isn't necessarily a good thing. This is blurring the
>>>>>> division of responsibility between the launcher and the VM when it
>>>>>> comes to argument processing. I don't see why a VM option file should
>>>>>> need to handle -Dxxx arguments - that suggests a need for a more
>>>>>> general command-file approach processed by the launcher.
>>>>> Hmmm... The above makes it sound like you think only the launcher
>>>>> handles '-DXXX' options.
>>>> No I'm aware that some properties get passed through specifically for
>>>> the VM to act upon (though arguably that was a bad decision back in
>>>> the day and the launcher could have used the properties to set VM
>>>> specific options); and also that the VM will set some properties for
>>>> the launcher and also JDK libs to act upon. This highlights just how
>>>> messy property processing is. By allowing properties to be set in a
>>>> VMOption file you are increasing the level of mess - in particular if
>>>> a property is examined by the launcher before it creates the VM, then
>>>> that property can not be specified in the VMOptions file. So now you
>>>> have something that will often work but for some special cases won't
>>>> work.
>>> Two things:
>>>
>>> 1)
>>>
>>>> in particular if a property is examined by the launcher before it
>>>> creates the VM, then that property can not be specified in the
>>>> VMOptions file.
>>> The new support for the '-XX:VMOptionsFile=foo' option simply
>>> provides another path to get options into our wonderfully
>>> complicated options processing mechanism. It uses the same
>>> processing path as the existing VM cmd line options mechanism
>>> so it has the same capabilities (and pitfalls) as that
>>> mechanism.
>> I don't quite see it that way. It isn't at all obvious to anyone what options on a long complex command-line get handled by whom and when. Anything in the VMOptions file will be invisible to the launcher, but that won't be obvious either.
>>
>>> If there is an option that must be handled by the launcher,
>>> then that option cannot be specified on the cmd line (as
>>> passed by the JNI invoke stuff). The new VMOptions file
>>> support is similarly limited. This same limitation applies
>>> to any other means of invoking the JVM without using our
>>> launcher. Nothing new here.
>> Your use of "cmd line" is confusing me here. The "cmd line" is what the user types in their shell and can contain any option. What options you can pass via the JNI invocation API is quite different to a command-line. I agree the VMOptions file is akin to the options you could pass via the invocation API to be processed only by the VM.
>>
>>> I believe Ron's write-up discusses launcher only options and
>>> when he returns next week he should be able to attach that
>>> document to the bug report.
>>>
>>> 2)
>>>
>>>> the VM will set some properties for the launcher and also
>>>> JDK libs to act upon
>>> I can see how the VM can set properties for the JDK libs
>>> and that is exactly what supporting the -Dfoo stuff is all
>>> about, but how/where is the VM setting properties for the
>>> launcher?
>> Sorry my mistake. I was mis-remembering what we do to force headless mode in some cases. But the launcher isn't involved in that. The launcher can't see properties set by the VM (unless it uses JNI to access the Java level data structures).
>>
>>>> Just makes me wonder whether this is something that should be handled
>>>> by the VM or by the launcher. Or (dare I say it) even by a shell
>>>> script. ;-)
>>> At least one version of Ron's write-up talked about where
>>> to put this new mechanism between the launcher and the
>>> VM... We'll have to see what the current draft says...
>>>
>>> Shell script? Bite your tongue! :-)
>> :)
>>
>> Cheers,
>> David
>>
>>
>>> Dan
>>>
>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> That is not correct... Here's the current
>>>>> code:
>>>>>
>>>>> src/share/vm/runtime/arguments.cpp
>>>>>
>>>>> 2691 // -D
>>>>> 2692 } else if (match_option(option, "-D", &tail)) {
>>>>> 2693 const char* value;
>>>>> 2694 if (match_option(option, "-Djava.endorsed.dirs=",
>>>>> &value) &&
>>>>> 2695 *value!= '\0' && strcmp(value, "\"\"") != 0) {
>>>>> 2696 // abort if -Djava.endorsed.dirs is set
>>>>> 2697 jio_fprintf(defaultStream::output_stream(),
>>>>> 2698 "-Djava.endorsed.dirs=%s is not supported. Endorsed
>>>>> standards
>>>>> and standalone APIs\n"
>>>>> 2699 "in modular form will be supported via the concept of
>>>>> upgradea
>>>>> ble modules.\n", value);
>>>>> 2700 return JNI_EINVAL;
>>>>> 2701 }
>>>>> 2702 if (match_option(option, "-Djava.ext.dirs=", &value) &&
>>>>> 2703 *value != '\0' && strcmp(value, "\"\"") != 0) {
>>>>> 2704 // abort if -Djava.ext.dirs is set
>>>>> 2705 jio_fprintf(defaultStream::output_stream(),
>>>>> 2706 "-Djava.ext.dirs=%s is not supported. Use -classpath
>>>>> instead.
>>>>> \n", value);
>>>>> 2707 return JNI_EINVAL;
>>>>> 2708 }
>>>>> 2709
>>>>> 2710 if (!add_property(tail)) {
>>>>> 2711 return JNI_ENOMEM;
>>>>> 2712 }
>>>>> 2713 // Out of the box management support
>>>>> 2714 if (match_option(option, "-Dcom.sun.management",
>>>>> &tail)) {
>>>>> 2715 #if INCLUDE_MANAGEMENT
>>>>> 2716 if (FLAG_SET_CMDLINE(bool, ManagementServer, true) !=
>>>>> Flag::SUCC
>>>>> ESS) {
>>>>> 2717 return JNI_EINVAL;
>>>>> 2718 }
>>>>> 2719 #else
>>>>> 2720 jio_fprintf(defaultStream::output_stream(),
>>>>> 2721 "-Dcom.sun.management is not supported in this
>>>>> VM.\n");
>>>>> 2722 return JNI_ERR;
>>>>> 2723 #endif
>>>>> 2724 }
>>>>>
>>>>>
>>>>> L2710 is where we add a property that is not already
>>>>> handled by special logic above that.
>>>>>
>>>>> $ java -showversion -XX:+PrintVMOptions -Dmy.property="This is my
>>>>> special property." DumpMyProperty
>>>>> VM option '+PrintVMOptions'
>>>>> java version "1.9.0-ea"
>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>
>>>>> my.property=This is my special property.
>>>>>
>>>>>
>>>>> In the above example, the "my.property" Java property is parsed
>>>>> by the above code in the VM. The launcher doesn't care about this
>>>>> particular property.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>>
>>>>>>> On 25.06.2015 8:01, David Holmes wrote:
>>>>>>>> On 25/06/2015 4:10 AM, Dmitry Dmitriev wrote:
>>>>>>>>> Hello Dan,
>>>>>>>>> I just want to add following: new VM Options file feature allow to
>>>>>>>>> define property inside option file.
>>>>>>>> What do you mean by that?
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dmitry
>>>>>>>>>
>>>>>>>>> On 24.06.2015 19:19, Daniel D. Daugherty wrote:
>>>>>>>>>> On 6/23/15 10:43 PM, John Rose wrote:
>>>>>>>>>>> On Jun 23, 2015, at 7:50 PM, David Holmes
>>>>>>>>>>> <david.holmes at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 24/06/2015 3:43 AM, Ron Durbin wrote:
>>>>>>>>>>>>> David,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The '-XX:Flags' option was considered during the research phase
>>>>>>>>>>>>> of this project and was rejected because of its limitations. The
>>>>>>>>>>>>> '-XX:Flags' option only works for boolean flag options and it
>>>>>>>>>>>>> uses a different syntax for the options than the command line.
>>>>>>>>>>>>> For example, '-XX:+UseSerialGC' would be specified as
>>>>>>>>>>>>> '+UseSerialGC'
>>>>>>>>>>>>> in the '-XX:Flags' option file.
>>>>>>>>>>>> I'm a little surprised the Flags option wasn't extended to cover
>>>>>>>>>>>> these additional requirements. But presumably it should now be
>>>>>>>>>>>> deprecated as we (again presumably) don't want to have two
>>>>>>>>>>>> mechanisms for doing this.
>>>>>>>>>>> I thought the Flags option used to handle any command line
>>>>>>>>>>> options,
>>>>>>>>>>> and like David I'm surprised the right answer is to get rid of it
>>>>>>>>>>> and
>>>>>>>>>>> make a new option that does what I think the Flags option
>>>>>>>>>>> should be
>>>>>>>>>>> doing.
>>>>>>>>>>>
>>>>>>>>>>> — John
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> Ron is out of the office until next week so I'll provide a little
>>>>>>>>>> bit of background...
>>>>>>>>>>
>>>>>>>>>> Ron has a detailed write-up documenting all the research that he
>>>>>>>>>> did on the various command line option mechanisms. We had planned
>>>>>>>>>> to attach that write-up to the bug report, but we dropped the ball
>>>>>>>>>> (Sorry Mary!) After Ron returns, we'll make a final editing pass
>>>>>>>>>> on the document and attach it to the bug report.
>>>>>>>>>>
>>>>>>>>>> I fleshed out the '-XX:Flags' test cases that Ron posted earlier
>>>>>>>>>> in the thread:
>>>>>>>>>>
>>>>>>>>>> $ more flags.input.*::::::::::::::
>>>>>>>>>> flags.input.boolean
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> +UseSerialGC
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> flags.input.ccstr
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> ErrorFile=my_error_file
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> flags.input.uintx
>>>>>>>>>> ::::::::::::::
>>>>>>>>>> MinRAMFraction=8
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.boolean -version
>>>>>>>>>> VM option '+UseSerialGC'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.boolean'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.ccstr -version
>>>>>>>>>> VM option 'ErrorFile=my_error_file'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.ccstr'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>> $ java -XX:+PrintVMOptions -XX:Flags=flags.input.uintx -version
>>>>>>>>>> VM option 'MinRAMFraction=8'
>>>>>>>>>> VM option '+PrintVMOptions'
>>>>>>>>>> VM option 'Flags=flags.input.uintx'
>>>>>>>>>> java version "1.9.0-ea"
>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b69)
>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b69, mixed mode)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It looks like the '-XX:Flags' option does work for 'bool', 'uintx'
>>>>>>>>>> and 'ccstr' options. Clearly Ron and I didn't remember the exact
>>>>>>>>>> reason that he ruled out using the '-XX:Flags' option. This part
>>>>>>>>>> of the review thread will have to be resolved after Ron returns.
>>>>>>>>>>
>>>>>>>>>> Dan
More information about the hotspot-runtime-dev
mailing list