RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v2]

[Kim Barrett]

On Mon, 22 Mar 2021 17:39:35 GMT, Amit Pawar <github.com+71302734+amitdpawar at openjdk.org> wrote:

> > > [PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx](https://github.com/openjdk/jdk/files/6147180/PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx)
> > 
> > 
> > I'm not sure how to interpret this. In particular, it says "Test done using November 27rd Openjdk build". That predates a number of recent changes in this area that seem relevant. Is that correct? Or is that stale and the data has been updated for a newer baseline.
> 
> Sorry for the confusion. I didnt test again and pre-touch time taken with different chunk size per thread was already recorded in the spreadsheet and thought to use it for reference to reply to David feedback "A change like this needs a lot more testing than that, both functionally and performance.".

Getting any benefit from parallel pretouch here suggests we have many threads piling up on the expand mutex. Before JDK-8260045 (pushed together with JDK-8260044 on 2/12/2021) that would lead to "expansion storms", where several threads piled up on that mutex and serially entered and did a new expansion (with associated pretouch, and possibly of significant size). Getting rid of the expansion storms may alleviate the serial pretouch quite a bit. There may still be some benefit to cooperative parallization, but new measurements are needed to determine how much of a problem still exists.

If it is still worth addressing, I think the proposed approach has problems, as it makes messy complicated code messier and more complicated.  I think some preliminary refactoring is needed.  For example, splitting MutableSpace::initialize into a setup-pages part and set-the-range part.  I've not explored in detail what's needed yet, pending new measurements.  (I haven't had time to do those measurements yet myself.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2976