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

[Thomas Stuefe]

On Tue, 19 Dec 2023 22:07:36 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/codecache/CheckLargePages.java line 72:
>> 
>>> 70:         OutputAnalyzer out = new OutputAnalyzer(pb.start());
>>> 71:         out.shouldMatch("Code cache size too small for \\S* pages\\. Reverting to smaller page size \\((\\S*)\\)\\.");
>>> 72:         out.shouldHaveExitValue(0);
>> 
>> I don't get this.
>> 
>> The new version (which I like, btw) now assumes min_pages=1 if InitialCCS == ReservedCCS. Should this not then work? I would have expected to get a code cache with 2x1G pages. I would not have expected a "code cache size too small" warning.
>
>> The new version (which I like, btw) now assumes min_pages=1 if InitialCCS == ReservedCCS.
> 
> It is only for the non-segmented CodeCache. Here we explicitly specify to use the segmented CodeCache. As such, we need to split 2G among three code heaps. InitialCCS is tricky in such a case, with the segmented CodeCache, the initial size of a code heap is the min of InitialCCS and the code heap size. We want the 2G segmented CodeCache to have 8 pages at least which is not possible with 1G pages. The number 8 is hard-coded. 
> 
> I think calculating the minimum number of pages is not easy for the segmented CodeCache.
> We have:
> - InitialCodeCacheSize
> - ReservedCodeCacheSize
> - LargePageSizeInBytes
> - NonNMethodCodeHeapSize
> - ProfiledCodeHeapSize
> - NonProfiledCodeHeapSize
> 
> It's too many parameters for users.
> 
> A possible configuration: one 1G page for the non-nmethod code heap and the profiled code heap, another 1G page for the non-profiled code heap.
> 
> BTW, this is the original first test.

Okay, I see.

We should probably allow the segmented code cache, in its entirety, to live on one or a few super large pages if we desire to; but I guess that would be too much changes for now. Not for this RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16582#discussion_r1432326345