RFR (S): 8202842: G1 footprint regressions in jdk11+10

[Stefan Johansson]

Hi Thomas,

On 2018-05-16 11:03, Thomas Schatzl wrote:
> Hi all,
> 
>    can I have reviews for this change that fixes (and actually improves
> upon the baseline) some startup footprint regression introduced by
> changes in jdk10+10?
> 
> Between jdk11+9 and jdk11+10 several G1 related changes added to the
> startup footprint:
> 
> - https://bugs.openjdk.java.net/browse/JDK-8196485 ("FromCardCache
> default card index can cause crashes") doubled the size of the
> FromCardCache internal data structure due to some memory overflow bug
> (which is #threads * #regions * 8 now instead of * 4)
> 
> - https://bugs.openjdk.java.net/browse/JDK-8180415 ("Rebuild remembered
> sets during the concurrent cycle") added at least one per-region * per-
> thread table (mark stats cache, result array), and also increased
> FromCardCache size due to more threads concurrently adding remembered
> set entries.
> 
> This change modifies the allocation of the FromCardCache to be
> allocated using mmap, which means that until it is touched, no actual
> memory is used.
> This works combined with a change to make the "invalid" FromCardCache
> entry have a value of zero - this is possible because the Java heap can
> never start at address 0x0.
> This is the main change and yields almost all footprint gains.
> 
> There is also some change to not initialize the MarkStatsCaches at
> initialization either, and although these are malloc'ed, also
> apparently not causing the respective page faults.
> The impact of this change is much smaller, as we don't control
> alignment of these arrays - and the size of that data structure is also
> much smaller.
> 
> However it would be nice to implement a more controlled allocation of
> these kinds of arrays in the future to make sure they are not
> initialized/touched at startup and only on use. That seemed to be out
> of scope here, and the other change already improved startup footprint
> beyond the original anyway. It was a very low-hanging fruit to pick
> though :)
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202842
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202842/webrev/
Looks good, thanks for doing the analysis and fixing this.

Cheers,
Stefan

> Testing:
> hs-tier1 to hs-tier3
> 
> Thanks,
>    Thomas
>