JDK-7080389 : G1: refactor marking code in evacuation pause copy closures
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs22
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-17
  • Updated: 2013-09-18
  • Resolved: 2011-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u2Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
JDK-7092412 - G1: Some roots not marked during an initial mark that gets an evacuation failure
Description
As part of 6484965, the following behavior was observed:

During root scanning of an initial mark pause, an object A is successfully forwarded by thread 1; thread 1 then proceeded to copy A to A'.

At the same time thread 2 sees that A has been forwarded, checks to see if A' has been marked (it has not yet), and successfully sets the bit for A' in the next marking bitmap.

After thread 1 has finished copying object A -> A', it calls mark_forwardee which checks to see if A' has been marked and it has.

The issue is that while thread 1 is copying A -> A', there is a window where if thread 2 attempts to get the size of A', it could see an unitialized object.

This has an implication for the preferred solution for 6484965. In the preferred solution, when an object is marked, we obtain its size in order to add to the marked bytes total.

The solution is to refactor the marking code in the G1 copy closures so that the thread that successfully for forwards and copies A is also responsible for marking A'.
Comments
EVALUATION See main CR
14-09-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/eeae91c9baba
29-08-2011
SUGGESTED FIX Push the mark_forwardee() calls from G1ParCopyClosure::do_oop_nv into G1ParCopyClosure::do_oop_work and G1ParCopyHelper::copy_to_survivor_space. Execute the code in copy_to_survivor_space that marks the copied object if the current closure is a root scan/mark closure, we're during an initial mark pause, or (we're during marking itself and) the old object has a mark that needs to be propagated to the new object. Try to use the template parameter (do_mark_forwardee) wherever possible to avoid additional runtime per object checks.
29-08-2011
EVALUATION Multiple threads attempt to mark the same forwarded object during an initial mark evacuation pause. Refactor code so that the thread which is successful in forwarding and copying an object will also mark the forwarded object.
17-08-2011