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

[Yasumasa Suenaga]

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

> 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>> 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150126/e2d94c44/attachment.htm>