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

[Kirk Pepperdine]

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. 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> 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>:
> 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: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150126/0615d7b2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150126/0615d7b2/signature-0001.asc>