RFR: 8334147: Shenandoah: Avoid taking lock for free set logging [v6]
Aleksey Shipilev
shade at openjdk.org
Thu Jun 27 15:48:14 UTC 2024
On Thu, 27 Jun 2024 15:43:07 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 344:
>>
>>> 342: void recycle_trash();
>>> 343: void log_status();
>>> 344: void log_status_with_heap_locked();
>>
>> Suggestion: this can be just `log_status_under_lock`. We already have other methods with `*_under_lock`.
>
> Checked some code in this name pattern:
>
> HeapWord* ShenandoahHeap::allocate_memory_under_lock(ShenandoahAllocRequest& req, bool& in_new_region) {
> // If we are dealing with mutator allocation, then we may need to block for safepoint.
> // We cannot block for safepoint for GC allocations, because there is a high chance
> // we are already running at safepoint or from stack watermark machinery, and we cannot
> // block again.
> ShenandoahHeapLocker locker(lock(), req.is_mutator_alloc());
> return _free_set->allocate(req, in_new_region);
> }
>
>
> It assumes lock is not acquired, lock is acquired in the method, I can change it to this pattern to align the naming conversions/patterns, but won't be a simple renaming.
Ah right. Okay, nevermind, whatever works.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19915#discussion_r1657369504
More information about the hotspot-gc-dev
mailing list