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

[Jeremy Manson]

No love?  Is there a code owner here I should pester more directly?

Jeremy

On Fri, Jun 26, 2015 at 3:00 PM, Martin Buchholz <martinrb at google.com>
wrote:

> As usual with Google patches, they are in use locally.  This one has been
> stable for a while without complaints.  Please sponsor.
>
> On Fri, Jun 26, 2015 at 1:53 PM, Jeremy Manson <jeremymanson at google.com>
> wrote:
>
>> 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
>>>>>
>>>>>
>>>
>>
>