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

[Jeremy Manson]

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
>>
>>