RFR: 8079301: Some command line options not settable via JAVA_TOOL_OPTIONS

[Jeremy Manson]

All this talk about IgnoreUnrecognizedVMOptions reminded me that this
review is still outstanding.  Any takers?

Jeremy

On Tue, May 5, 2015 at 10:01 AM, Jeremy Manson <jeremymanson at google.com>
wrote:

> Hi David,
>
> Thanks for taking a look.
>
> On Mon, May 4, 2015 at 8:32 PM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Jeremy,
>>
>> On 5/05/2015 6:51 AM, Jeremy Manson wrote:
>>
>>> Not sure who might be willing to sponsor this.  David?  You did the last
>>> one.  :)
>>>
>>
>> Might be a while before I can get to it. I did have a quick look (and
>> will need a longer one).
>
>
> I understand.  I'm just happy it's possible to upstream this stuff at
> all[1].
>
> [1] With the eternal caveat that I'd be happier if we didn't *have* to go
> through you folks, but we've learned to live with it.
>
>
>
>>  Context: A number of command line options are not settable via
>>> JAVA_TOOL_OPTIONS and _JAVA_OPTIONS:
>>>
>>>    - PrintVMOptions
>>>
>>
>> So you have changed the semantics of this to print out the options from
>> the command-line and each of the two env vars. Seems reasonable but may be
>> better to know which option came from where as we can now see the same
>> option (or conflicting variants thereof) multiple times.
>>
>
> I'd be happy to do this.  Any preferred syntax?  Does someone actually own
> this feature?
>
> I'm unclear what the current processing order is for the different sources
>> of options, and whether the changes affect that order?
>>
>
> Nope.  I go through sad contortions to keep the processing order the
> same.  It's JAVA_TOOL_OPTIONS, then command line, then _JAVA_OPTIONS.  See
> lines 2549-2567.
>
>
>>
>>     - IgnoreUnrecognizedVMOptions
>>>    - PrintFlagsInitial
>>>
>>
>> Unclear what "initial" actually means - is it the default?
>
>
> More or less.  If you stick, for example, IgnoreUnrecognizedVMOptions in
> there first, it will get printed out as "true".  I haven't really changed
> the semantics here either - I've just added processing of the envvars.
>
>     - NativeMemoryTracking
>>>    - PrintFlagsWithComments
>>>
>>> This is because these flags have to be processed before processing other
>>> flags, and no one ever bothered to do that for the flags coming from
>>> environment variables.  This patch fixes that problem.
>>>
>>> I have a test, but it is a modification to a JDK test instead of a HS
>>> test,
>>> so it can go in separately (I guess).
>>>
>>
>> They can be pushed together to different repos in the same forest.
>>
>
> Okay.  Here's the test change:
>
> http://cr.openjdk.java.net/~jmanson/8079301t/webrev.00/
>
>
>> As I said I'll have to get back to this. And hopefully someone else in
>> runtime will take a good look as well ;-)
>>
>
> I'd be happy to toss it over to whomever owns this, if anyone.  Thanks!
>
> Jeremy
>
>
>
>>
>>  Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8079301
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jmanson/8079301/webrev.00/
>>>
>>> Jeremy
>>>
>>>
>