RFR: 8261230: GC tracing of page sizes are wrong in a few places

[Albert Mingkun Yang]

On Thu, 11 Feb 2021 16:20:07 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> The usage of `os::trace_page_sizes()` and friends are wrongly assuming that we always get the page size requested and needs to be updated. This is done by using the helper `ReservedSpace::actual_reserved_page_size()` instead of blindly trusting we get what we ask for. I have plans for the future to get rid of this helper and instead record the page size used in the `ReservedSpace`, but for now the helper is good enough. 
>> 
>> In G1 we used the helper but switched the order of the page size and the alignment parameter, which in turn helped the test to pass since the alignment will match the page size we expect in the test. The test had to be improved to recognize mapping failures.
>
> test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java line 59:
> 
>> 57:     static void checkSize(OutputAnalyzer output, long expectedSize, String pattern) {
>> 58:         // First check if there is a large page failure associated with
>> 59:         // the data structure being checked.
> 
> Are you thinking something like this @albertnetymk?
> Suggestion:
> 
>         // First check if there is a large page failure associated with
>         // the data structure being checked. In case of a large page 
>         // allocation failure the output will include logs like this for 
>         // the affected data structure:
>         // [0.048s][debug][gc,heap,coops] Reserve regular memory without large pages
>         // [0.048s][info ][pagesize     ] Next Bitmap: ... page_size=4K ...

Yes, and also for `checkLargePagesEnabled`. It's not obvious to me why we parse the output in those two places, one looking for the failure mode, and the other looking for the success mode. That's why I asked for an sample of the "expected" log output.

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

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