JDK-8034873 : Concurrent collection set freeing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-02-13
  • Updated: 2019-02-11
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8027295 - Free CSet takes ~50% of young pause time
Relates :  
JDK-8034842 - Parallelize the Free CSet phase in G1
Description
Recent efforts in the area of collection set freeing concentrated on improving serial performance or parallelizing the existing method (JDK-8027295 and JDK-8034842).

Another option is to look into doing the CSet freeing work concurrently after the pause has completed, instead of in parallel at the end of the pause. There's already a mechanism in G1 to free regions concurrently (look at how the CM cleanup phase frees regions concurrently and makes them available on the secondary free list).

It should be possible to re-use a similar mechanism to also free the collection set regions too.

(after a recommendation by Tony P. in the comments for JDK-8027295)
Comments
Comments taken from JDK-8027295 since they are relevent to this CR: Thomas (https://bugs.openjdk.java.net/browse/JDK-8027295?focusedCommentId=13457540&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13457540) "Going to see what and if work can be done concurrently, thanks for the idea. Problem seems that 500ms is already quite long, and may cause this work to spill over into the next pause (if done only by a single thread). Concurrent operation sounds particularly attractive for the cases when parallelizing does not make sense (due to long worker task synch time), but still takes a significant time of the pause." Tony Printezis (https://bugs.openjdk.java.net/browse/JDK-8027295?focusedCommentId=13461978&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13461978) ""Problem seems that 500ms is already quite long, and may cause this work to spill over into the next pause (if done only by a single thread)." A couple of things: First, if CSet freeing takes 500ms, I assume the CSet is quite large, hence the eden is also quite large. So, you're probably not going to fill it up very quickly to require another GC after 500ms. Second, note that the concurrent freeing process at the end of marking will actually work through a GC pause to make regions available if they are required by the GC (look at how the secondary free list is used). So, if a GC does happen it doesn't necessarily have to wait for the concurrent process to finish (of course, as long as it doesn't happen often; the concurrent process will eventually fall behind and it might have to do a safepoint to catch up). Speeding up the freeing operation is of course always good (whether it's done at a safepoint or concurrently)! But, IMHO, the only way to totally eliminate this overhead is to do the work concurrently." Thomas (https://bugs.openjdk.java.net/browse/JDK-8027295?focusedCommentId=13461992&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13461992) I agree on all your points, particularly on your conclusion. This problem just needs to be taken under consideration when implementing that - that was just mention of a possible pain point. Do you mind moving over to JDK-8034873 when discussing concurrent cset freeing? I will copy your helpful comments manually this time because I am sure they will be forgotten here :)
14-02-2014