[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8079301: Some command line options not settable via JAVA_TOOL_OPTIONS
From:       Martin Buchholz <martinrb () google ! com>
Date:       2015-06-26 22:00:52
Message-ID: CA+kOe09frCFHqTQtMy0N0j=GBAFvVkWLG7AyqmMDpk3x4Y1emA () mail ! gmail ! com
[Download RAW message or body]

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@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@google.com>
> wrote:
>
>> Hi David,
>>
>> Thanks for taking a look.
>>
>> On Mon, May 4, 2015 at 8:32 PM, David Holmes <david.holmes@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
>>>>
>>>>
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]