RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

[Frederic Parain]

On 01/26/2015 09:28 AM, Kirk Pepperdine wrote:
> Hi Yasumasa,
>
> Thank you for your review of the code. Indeed you have filed this as a
> bug and it has been commented on as an enhancement, not a bug. As I have
> mentioned a single call to System.gc() makes no difference in any
> analytic that I performed on any application that I’ve encountered in
> the wild no matter what the cause. Other issues: it’s not currently
> clear to me that jcmd is the only entry point to this call and that
> would make the message misleading for those other paths. There are other
> entry points that can results in a full GC but they will remain labeled
> as is.

Correct. It is possible to externally trigger a full GC using the
PlatformMBean server, and invoking the 
java.lang.management.MemoryMXBean.gc() operation.
In this case, the gcCause is also "System.gc()".

Fred

> I also see a downstream impact on tooling. Thus I don’t see a
> compelling argument for the value of this change thus I will argue
> towards not destabilizing downstream tooling.
>
> That said, I’ve said my piece and have added enough spam to the list on
> this subject.
>
> Kind regards,
> Kirk Pepperdine
>
>
> On Jan 26, 2015, at 4:53 AM, Yasumasa Suenaga <yasuenag at gmail.com
> <mailto:yasuenag at gmail.com>> wrote:
>
>> Hi Kirk,
>>
>> I want to distinguish GC whether it is requested from internal (e.g.
>> System.gc()) or not.
>> System.gc() is called in RMI as you said.
>>
>> In JVM implementation, entry point of GC is
>> Universe::heap()->collect() family. It is used by JVMTI force GC, heap
>> inspection (e.g. jmap), etc. Thus I guess that GCCause which is
>> invoked from JVM should set valid GCCause which is not System.gc().
>> So I file this enhancement to JBS and create a patch.
>>
>> Thanks,
>>
>> Yasumasa
>>
>> 2015/01/26 6:14 "Kirk Pepperdine" <kirk at kodewerk.com
>> <mailto:kirk at kodewerk.com>>:
>>
>>     Hi Yasumasa,
>>
>>
>>     >
>>     > I think the System.gc() call which is invoked by jcmd is special
>>     case and I want to
>>     > distinguish it.
>>     > Programmer can call System.gc() from their code. But GC which is
>>     invoked by jcmd is NOT explicitly call by programmer.
>>
>>     System.gc() called for by RMI is also not explicitly called by the
>>     programmer either. There are also other tools that will result in
>>     calls to System.gc() also. Should we catalog them in GCCause also?
>>
>>     >
>>     > Indeed, SystemGCDCmd will call System.gc() (same meaning).
>>     > However, I think it has different meaning from System.gc() call
>>     from source code.
>>
>>     I’m not sure I understand the point. From an analytical POV, a
>>     single call to System.gc() is pretty much meaningless. If it’s
>>     regular or there is a pattern in the frequency of the calls then
>>     I’m interested. A call to System.gc() has the same effect no
>>     matter who or why is responsible.
>>
>>     My interest lies in keeping the GC logs as simple as possible. If
>>     there is meaningful data to add so be it. That said, I’m not sure
>>     that this change meets that bar.
>>
>>     That said, I’m still concerned that the caller/callee division
>>     seems inside out. But it’s Sunday so…
>>
>>     Kind regards,
>>     Kirk Pepperdine
>>
>>     >
>>     >
>>     > Thanks,
>>     >
>>     > Yasumasa
>>     >
>>     >
>>     > On 2015/01/25 22:56, Kirk Pepperdine wrote:
>>     >> Hi,
>>     >>
>>     >> IMHO, if a System.gc() is being called then the cause should be
>>     System.gc(). If we start down the road of differentiating between
>>     the various causes of calls to System.gc() this will turn in a
>>     nightmare!
>>     >>
>>     >> Indeed as I look at the patch it’s curious that it’s up to the
>>     caller to determine is calls to System.gc() have been suppressed.
>>     I would have expected the collect() call to make the decision as
>>     to should the call be honored or not.
>>     >>
>>     >>  void SystemGCDCmd::execute(DCmdSource source, TRAPS) {
>>     >>    if (!DisableExplicitGC) {
>>     >>     Universe::heap()->collect(GCCause::_jcmd_gc_run);
>>     >>    } else {
>>     >>      output()->print_cr("Explicit GC is disabled, no GC has
>>     been performed.");
>>     >>    }
>>     >>
>>     >>
>>     >>
>>     >> Kind regards,
>>     >> Kirk Pepperdine
>>     >>
>>     >> On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga
>>     <yasuenag at gmail.com <mailto:yasuenag at gmail.com>
>>     <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>> wrote:
>>     >>
>>     >>> Hi all,
>>     >>>
>>     >>> GCCause which is printed in gc log is "System.gc()" when jcmd
>>     GC.run is invoked.
>>     >>> I think that GCCause which is caused by jcmd GC.run should be
>>     different from System.gc() .
>>     >>>
>>     >>> I uploaded webrev for this enhancement:
>>     >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/
>>     >>>
>>     >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is
>>     invoked.
>>     >>>
>>     >>>
>>     >>> Could you review it?
>>     >>>
>>     >>>
>>     >>> Thanks,
>>     >>>
>>     >>> Yasumasa
>>     >>
>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com