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