RFR (M): 8004687: G1: Parallelize object self-forwarding and scanning during an evacuation failure

[Thomas Schatzl]

Hi all,

  some additional comments for better understanding:

On Thu, 2015-07-16 at 11:40 +0200, Thomas Schatzl wrote:
> (resend with CR number in the subject)
> Hi all,
> 
>   can I have reviews for the following change from a student (Walter
> Gugenberger; he has signed the OCA) who worked on this issue last
> semester?
> 
> The change parallelizes object self-forwarding and scanning during an
> evacuation failure by:
> - reuse the entire existing evacuation copy closure and work queue
> mechanism in case of evacuation failure to store the work items.
> This allows evacuation failure to automatically benefit from work
> stealing etc.
> - remove the dedicate evacuation failure handling closure because it is
> not necessary any more.
>   - there is one subtle change in behavior: the old evacuation failure
> always had a NULL ReferenceProcessor, while now the standard reference
> processor for references is applied. Since the NULL ReferenceProcessor
> kept all references alive, now potentially less references will be kept
> alive after an evacuation failure. I do not see a problem here.
> - implementing per-thread preserved mark buffers
> 
> As for actual performance improvements, there is none: the main problem
> is that in case of evacuation failure the code will simply serialize on
> the FreeList_lock when trying to get a new allocation region instead of
> the EvacFailureStack_lock.

The reason why we serialize on the FreeList_lock is that the current
allocation path always falls through to in the end try to allocate a new
allocation region (because during evacuation failure there is no more
space left). This requires obtaining that FreeList_lock.

In situations where not many objects fail like if we only slightly
underestimate the amount of space needed for the collection, which is a
fairly common case (unless you force the problem due to misconfiguration
like I did for some of my measurements :) ), the FreeList_lock may not
be contended as much and so there are already significant visible
performance improvements in some cases.

> Evacuation failure and the early-exit for evac failure as suggested in
> the CR will only be really effective when the FreeList_lock can be
> avoided. This will be added in a follow-up change.

The main reason for this (arbitrary) split is that I wanted to make the
full change more easily reviewable.

> CR:
> https://bugs.openjdk.java.net/browse/JDK-8004687
> 
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8004687/webrev/
> 
> Testing:
> jprt, lots of internal evacuation failure testing, aurora runs with vm.quick/vm.gc nightly tests etc.
> 

Thanks,
  Thomas