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

[Jon Masamitsu]

Thomas,

Changes look good.

Would it work to change

OopAndMarkOop
to
OopAndOldMarkOop

and change the constructor to

866     OopAndMarkOop(oop obj) : _o(obj), _m(markOop(obj))

so that OopAndOldMarkOop specifically saves the oop and it's
markword rather than just an oop and (not necessarily related)
markword?

An enhancement to be considered now or later. You have
OopAndMarkOop now.  Could you pass an OopAndMarkOop
around instead of  an oop and a markword pair.  For
example, starting with

201 oop copy_to_survivor_space(InCSetState const state, oop const obj, 
markOop const old_mark);

substitute passing an OopAndMarkOop in place of the obj and old_mark.

Reviewed.

Jon

On 7/16/2015 2:40 AM, 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.
>
> 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
>
>
>
>
>