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

Thomas Schatzl thomas.schatzl at oracle.com
Thu Jul 16 09:40:12 UTC 2015


(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.

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.

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







More information about the hotspot-gc-dev mailing list