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

[Stefan Johansson]

On Thu, 11 Feb 2021 16:29:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> 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.

I think the check if large pages are enable is pretty straight forward. We should never expect large page sizes in the output unless large pages are enabled. I do however agree that this check is a bit clunky. Would it help to extract it to a separate function? Something like `largePagesAllocationFailure(pattern)`, I could also change the name of the function above to just be `largePagesEnabled()` then the code reads even better?

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

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