RFR: Use distinct "end of cycle" message for each Shenandoah pause [v2]

William Kemper wkemper at openjdk.org
Wed May 3 17:11:53 UTC 2023


On Wed, 3 May 2023 01:10:48 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move region aging into op_final_roots
>
> src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 52:
> 
>> 50: 
>> 51: void VM_ShenandoahInitMark::doit() {
>> 52:   ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT);
> 
> Not your code, but I am curious how the 3rd argument "reason_type" `{MINOR, FULL, CONCURRENT}` is even ever used. I saw it dutifully passed around and eventually get used only to check whether it was `== FULL` or not, down in `VM_GC_Operation::notify_gc_begin`.

Yeah, I traced that too. It ultimately ends up exposed to DTRACE probes. There are quite a few GC monitoring/event hoops to jump through.

> src/hotspot/share/services/memoryManager.cpp line 297:
> 
>> 295:     if (is_notification_enabled()) {
>> 296:       const char* message = notificationMessage != nullptr ? notificationMessage : _gc_end_message;
>> 297:       GCNotifier::pushNotification(this, message, GCCause::to_string(cause));
> 
> This looks great to me. I am assuming all collectors that do their work in multiple pieces (at least ZGC and possibly G1 too) might want to make use of this functionality.
> 
> I am guessing this might benefit from an upstream review at some point.

Yes, I reckon so. I will target these changes for upstream as well.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/270#discussion_r1183976135
PR Review Comment: https://git.openjdk.org/shenandoah/pull/270#discussion_r1183976619


More information about the shenandoah-dev mailing list