RFR: 8319795: Static huge pages are not used for CodeCache [v7]

[Evgeny Astigeevich]

On Thu, 30 Nov 2023 00:02:29 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> This is a fix of a regression introduced by [JDK-8261894](https://bugs.openjdk.org/browse/JDK-8261894).
>> After JDK-8261894, `os::can_execute_large_page_memory()` returns `true` only if `UseTransparentHugePages` is true. As CodeCache uses `os::can_execute_large_page_memory()` when it detects a page size, CodeCache cannot use static huge pages (`UseTransparentHugePages` is `false`) anymore after the change.
>> Before JDK-8261894, `os::can_execute_large_page_memory()` returned `true`  when either `UseTransparentHugePages` or `UseHugeTLBFS` was true.
>> 
>> After JDK-8261894, `XX:+UseLargePages XX:-UseTransparentHugePages` means to use static huge pages: aka `UseHugeTLBFS` is `true`. If `UseLargePages` is not set to `true` via the option, it will be set to `true` if `UseTransparentHugePages` is `true`.
>> 
>> `os::can_execute_large_page_memory()` is modified to return `UseLargePages`. A regression gtest  is added.
>> 
>> Tested fastdebug and release builds:
>> - [x] tier1
>> - [x] gtest
>> - [x] test/hotspot/jtreg/gtest/LargePageGtests.java
>
> Evgeny Astigeevich has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix support of explicit huge pages
>  - Revert "Refactor CodeCache init code for better support of different memory page sizes"
>    
>    This reverts commit 5416895d565923b7689b3059af68bd9011c61705.
>  - Revert "Add missing include"
>    
>    This reverts commit c35739fccf05c12969083d5c14c3750b5920fc21.
>  - Revert "Align ReservedCodeCacheSize to max(preferred page size, os::vm_allocation_granularity())"
>    
>    This reverts commit f495310ef48791d851ef37eb3fb1d559dabf329e.
>  - Revert "Fix code heap sizes to be multiple of rs.alignment()"
>    
>    This reverts commit 41cc20b2e488647468de009d13085ea7882d5437.
>  - Revert "Fix code heap initial sizes to be multiple of rs.alignment()"
>    
>    This reverts commit 17c42cddd220a0f47f8b944271d9b96b32e51b59.

Linux x86_64, 200 2MB pages, 10 1GB pages, the following tests passed:

hotspot/jtreg/compiler/codecache/jmx/InitialAndMaxUsageTest.java
hotspot/jtreg/gc/arguments/TestAlignmentToUseLargePages.java
hotspot/jtreg/gc/arguments/TestNewRatioFlag.java
hotspot/jtreg/gc/arguments/TestNewSizeFlags.java
hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java
hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java
hotspot/jtreg/gc/g1/TestLargePageUseForHeap.java
hotspot/jtreg/gc/metaspace/TestMetaspaceSizeFlags.java
hotspot/jtreg/gc/shenandoah/options/TestLargePages.java
hotspot/jtreg/gc/shenandoah/options/TestLargePagesWithSmallHeap.java
hotspot/jtreg/gc/shenandoah/TestHeapUncommit.java
hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java
hotspot/jtreg/gc/TestNUMAPageSize.java
hotspot/jtreg/gc/TestSystemGC.java
hotspot/jtreg/gtest/LargePageGtests.java
hotspot/jtreg/runtime/cds/appcds/CommandLineFlagCombo.java
hotspot/jtreg/runtime/cds/appcds/SharedRegionAlignmentTest.java
hotspot/jtreg/runtime/cds/appcds/sharedStrings/InternSharedString.java
hotspot/jtreg/runtime/cds/appcds/sharedStrings/LargePages.java
hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java
hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java
hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
hotspot/jtreg/runtime/os/TestHugePageDecisionsAtVMStartup.java
hotspot/jtreg/runtime/os/TestTracePageSizes.java
hotspot/jtreg/vmTestbase/gc/memory/LargePagesTest/LargePagesTest.java


The test `hotspot/jtreg/compiler/codecache/CheckLargePages.java` passed with [the regex fix](https://github.com/yftsai/jdk/compare/master...yftsai:jdk:JDK-8317831#diff-9894fc5c648bf7884ce182cd1d162ebac09789d20bc2ef6614bb76b40e3f121dR65).

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

PR Comment: https://git.openjdk.org/jdk/pull/16582#issuecomment-1839573876