Hi Staffan, There are other entry points in diagnosticCommand that will trigger a Full GC.
void ClassHistogramDCmd::execute(DCmdSource source, TRAPS) {
VM_GC_HeapInspection heapop(output(),
!_all.value() /* request full gc if false */);
VMThread::execute(&heapop);
}
and
void HeapDumpDCmd::execute(DCmdSource source, TRAPS) {
// Request a full GC before heap dump if _all is false
// This helps reduces the amount of unreachable objects in the dump
// and makes it easier to browse.
HeapDumper dumper(!_all.value() /* request GC if _all is false*/);
int res = dumper.dump(_filename.value());
if (res == 0) {
output()->print_cr("Heap dump file created");
} else {
// heap dump failed
ResourceMark rm;
char* error = dumper.error_as_C_string();
if (error == NULL) {
output()->print_cr("Dump failed - reason unknown");
} else {
output()->print_cr("%s", error);
}
}
}
For example. For consistency, how would you suggest these be handled.
Kind regards,
Kirk Pepperdine
On Jan 26, 2015, at 9:12 AM, Staffan Larsen <staffan.lar...@oracle.com> wrote:
> A bit of terminology here. ‘GC.run’ is called a ‘Diagnostic Command’. ‘jcmd’
> is one way to invoke a Diagnostic Command. Another way is via a JMX MBean.
> With this in mind I think your references to ‘jcmd’ should be changed to
> ‘diagnostic command’ (or an abbreviation thereof). For example: _jcmd_gc_run
> -> _dcmd_gc_run.
>
> Thanks,
> /Staffan
>
>> On 25 jan 2015, at 14:15, Yasumasa Suenaga <yasue...@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
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
