- 
    Enhancement 
- 
    Resolution: Fixed
- 
     P4 P4
- 
    None
- 
        b14
                    This method is the allocation entry API for mutators. Its flow is the following
1. try young-gen
2. try old-gen
3. invoke GC operation
4. if GC-op succeeds, return; otherwise, go to 1
Before step 3, we need to call `total_collections()`, which requires holding `Heap_lock`. The current code invokes old-gen allocation while holding `Heap_lock`.
However, the old-gen allocation API supports multi-thread, so it can be moved outside the critical-region. This cleans up the structure and streamlines the flow.
1. try young-gen
2. try old-gen
3. invoke GC operation
4. if GC-op succeeds, return; otherwise, go to 1
Before step 3, we need to call `total_collections()`, which requires holding `Heap_lock`. The current code invokes old-gen allocation while holding `Heap_lock`.
However, the old-gen allocation API supports multi-thread, so it can be moved outside the critical-region. This cleans up the structure and streamlines the flow.
- causes
- 
                    JDK-8367665 Regressions in SPECjbb2005-ParGC (~6%) and SPECjvm2008-SOR.large-ParGC (~1-5%) on Linux x64/AArch64 from JDK-8365557 and/or JDK-8366063 -           
- Closed
 
-         
- relates to
- 
                    JDK-8367737 Parallel: Retry allocation after lock acquire in mem_allocate_work -           
- Resolved
 
-         
- links to
- 
                     Commit(master)
        openjdk/jdk/1feb9bd5 Commit(master)
        openjdk/jdk/1feb9bd5
- 
                     Review(master)
        openjdk/jdk/26779 Review(master)
        openjdk/jdk/26779