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

List:       openjdk-serviceability-dev
Subject:    Re: jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set.
From:       Mikael Gerdin <mikael.gerdin () oracle ! com>
Date:       2017-08-29 9:59:48
Message-ID: 2089c3f4-6ebd-b451-3720-55b92fb7f955 () oracle ! com
[Download RAW message or body]

Hi Kevin,

On 2017-08-29 11:14, Kevin Walls wrote:
> 
> Hi Mikael, thanks yes, it could be a separate cmd GC.runForce... However 
> I was thinking if you can get as far as having your jcmd executed, you 
> really _do_ want to run that collection.  Whatever behaviour you were 
> protecting against when you chose the command-line arguments, you would 
> only ever want to override if you run the jcmd to invoke GC... 8-)

I was more thinking of
jcmd GC.run force=1

> 
> I'll convert this to a review request for removing that check, will post 
> that shortly.  This would be changing the behaviour, but I don't think 
> it contradicts anything we document, and we seem to have added the check 
> without documenting it.

Sounds good.
/Mikael

> 
> Thanks
> Kevin
> 
> 
> On 28/08/2017 16:01, Mikael Gerdin wrote:
>> Hi Kevin,
>>
>> On 2017-08-22 16:38, Kevin Walls wrote:
>>> Hi,
>>>
>>> jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this 
>>> seems like a mistake?
>>>
>>> This behaviour is obstructive for a live app that _needs_ a GC, and 
>>> was started with -XX:+DisableExplicitGC.
>>>
>>> DisableExplicitGC to protect from Java code calling System.gc 
>>> frequently makes sense, but if I can attach and run a dcmd, I should 
>>> have permission to inspect and maintain the JVM, including invoking a 
>>> GC. (This is as the user who owns the process and can kill it off.)
>>>
>>> The behaviour (checking DisableExplicitGC in SystemGCDCmd::execute) 
>>> comes in with:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8004095
>>> 8004095: Add support for JMX interface to Diagnostic Framework and 
>>> Commands
>>>
>>> The JMX relation I suppose suggests we didn't want JMX to override 
>>> DisableExplicitGC by way of using a jcmd/DCmd.
>>>
>>> But also, we now have:
>>> 8072913: [REDO] GCCause should distinguish jcmd GC.run from System.gc()
>>> Summary: GCCause which is caused by GC.run diagnostic command should 
>>> be different from System.gc() .
>>>
>>> ..at least the causes are distinct.
>>>
>>> I don't think we document this clearly.  Our comment in globals.hpp 
>>> is ""Ignore calls to System.gc()".  I don't think we say anywhere 
>>> that jcmd is subject to being disabled by the flag.
>>>
>>> Interested to hear any reason in favour of the current behaviour!  If 
>>> there's nothing, I'll log a bug and ask for review of the change to 
>>> remove it...
>>
>> There were some discussions earlier around this area and I came up 
>> with the idea of having a "force" option to the GC.run command to 
>> override DisableExplicitGC.
>> The comments in globals.hpp are a notoriously bad spec for the flags 
>> since they are only ever present in debug builds of the JVM.
>>
>> Thanks
>> /Mikael
>>
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>>
> 
[prev in list] [next in list] [prev in thread] [next in thread]