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