RFR: 8280136: Serial: Remove unnecessary use of ExpandHeap_lock [v4]

[Kim Barrett]

On Thu, 10 Feb 2022 17:23:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR consists of two commits:
>> 
>> 1. remove `ExpandHeap_lock` in Serial GC code.
>> 2. rename it to `ParallelExpandHeap_lock` to indicate it's Parallel-GC only.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lower case

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/parallel/psOldGen.cpp line 48:

> 46: #else
> 47:   _expand_lock(Mutex::safepoint, "PSOldGenExpand_lock", true)
> 48: #endif

I think this is the only relative lock rank outside of mutexLocker.  I didn't realize that when I suggested the possibility of a private mutex.  I'd prefer the definition and rank calculation be left in mutexLocker.

src/hotspot/share/gc/parallel/psOldGen.cpp line 179:

> 177:     // expand.  That's okay, we'll just try expanding again.
> 178:     bool needs_expand =
> 179:       pointer_delta(object_space()->end(), object_space()->top()) < word_size;

This has lost the comment in the `needs_expand` function about the stability of end() and the associated implications for access ordering.  I'd like to keep that information.

src/hotspot/share/gc/parallel/psOldGen.cpp line 283:

> 281:   size_t size = align_down(bytes, virtual_space()->alignment());
> 282:   if (size > 0) {
> 283:     assert_lock_strong(&_expand_lock);

[pre-existing] Redundant with the assert at the beginning of the function.

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

PR: https://git.openjdk.java.net/jdk/pull/7124