RFR: 8252221: Use multiple workers for Parallel GC pre-touching

[Thomas Schatzl]

Hi,

On 25.09.20 14:27, Amit Pawar wrote:
> On Fri, 18 Sep 2020 16:56:42 GMT, Amit Pawar <github.com+71302734+amitdpawar at openjdk.org> wrote:
> 
> Hi Thomas,
> 
> Thanks for replying again and will do as per your suggestion.
> 
> Regarding using multiple threads to pre-touch old gen post resize.
> Initial debugging showed that GC threads do reach here to initialize old gen memory post resizing. This limits to
> single threaded only as GC thread is already executing a task and needs special handling. Please see generated log
> messages below that included thread name.
> 
> 2.116s][debug][gc   ] GC(9) Expanding ParOldGen thread name VM Thread from 5632K by 3584K to 9216K
> 2.249s][debug][gc   ] GC(12) Expanding ParOldGen thread name VM Thread from 9216K by 6144K to 15360K
> 5.768s][debug][gc   ] GC(33) Expanding ParOldGen thread name GC Thread#139 from 15360K by 512K to 15872K
> 5.769s][debug][gc   ] GC(33) Expanding ParOldGen thread name GC Thread#92 from 15872K by 512K to 16384K
> 5.769s][debug][gc   ] GC(33) Expanding ParOldGen thread name GC Thread#13 from 16384K by 512K to 16896K

So basically the threads themselves do expansion themselves during gc if 
they are out of memory. Makes sense.

> 
> I would like to fix this in two separate patches.
> 
> 1st Patch: Current PR fixes JVM startup time only. Pre-touching post resize do it multi-threaded with VM thread and
> single threaded with non VM threads. This will be a partial fix but not complete. Complete fix can be done in second
> patch.
> 
> 2nd Patch: Please check log messages from 33th GC. Old gen size was changed three times in the same GC by three
> different GC threads. This makes separate Pre-touching needs to be done post every resize. In the second patch this can
> be done once by combining after all the resizes. I am interested in fixing this but need more time.
> 
> Please suggest.

This looks like expansion of old gen during promotion. I did not think 
of that when replying earlier.

I do not think this can be delayed as the thread is simply out of 
uncommitted memory and needs it right now to continue evacuation.

Let's at least split this out into a separate change then as you 
suggested. If you can find something to improve here do it in another 
change.

Thanks,
   Thomas