JDK-8218668 : Clean up evacuation of optional collection set
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-02-08
  • Updated: 2022-03-01
  • Resolved: 2019-04-08
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 13
13 b16Fixed
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
In JDK-8190269/JDK-8213890 we added abortable mixed gc, ie. parts of the collection set during mixed gc were collected incremementally as pause time permitted.

Some of these issues have been pointed out in reviews, but moved for later.

There are a quite a few opportunities to clean up the code:
- the optional collection set evacuation duplicates quite a bit of "first pass" evacuation code while conceptually very similar. This should be unified and cleaned up as much as possible.
- with the optional collection set the code creates copies of parts of the candidate collection set, first popping it from it and then pushing back leftovers. This is not necessary, an index (cursor) within the candidate collection set is sufficient.

Some imho benign real issues with the current implementation, that are partially caused by the code duplication:
- if there is an evacuation failure during evacuating an optional part, we try to fix up self-looped oops for the entire collection set which is not necessary. Obviously only regions part of the current collection pass need to be looked at.
- the work distribution when evacuating an optional collection set is bad: every thread processes the same regions in the same sequence
- calculation of total number of cards scanned and total scan RS time does not take optional evacuation into account
- optional collection set log does not show code roots time (from the heap region's remembered sets) and termination time completely
- optional collection also does not add "code root fixup time"
- optional collection does not add to the "par time" (which is actually the time for the parallel evacuation), which means that the calculation for the "Other" time is wrong (result too high) impacting prediction (being too conservative)
- the opt_index_in_cset of a heap region is not reset for all regions every time after GC. Since it is properly overwritten as needed this seems benign.

Note that since the amount of optional regions/additional passes over the remembered set are typically rather small, there is no real performance problem.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/c4f16445675a User: tschatzl Date: 2019-04-08 18:39:05 +0000
08-04-2019