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

[Kirk Pepperdine]

Hi,

I take it there is enough support to make this type of change. In which case it seems sensible to change the implementation to reflect Staffan’s comments.

Kind regards,
Kirk Pepperdine

On Jan 27, 2015, at 11:10 AM, Frederic Parain <frederic.parain at oracle.com> wrote:

> 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

-------------- 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: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150127/8fddc1fa/signature.asc>