On Thu, 23 Jul 2026 06:36:39 GMT, Thomas Stuefe <[email protected]> wrote:
>> Linux s390x is special in that the kernel can expand a process' page table >> dynamically *during its runtime*. That is pretty cool, but it poses some >> problems for us. >> >> Expansion happens in three steps: >> - three levels (42 bits, max 4TB) >> - 4 levels (53 bits, 8PB) >> - 5 levels (64 bits, 16EB). >> >> It only works one-way - once switched to a higher level, there is no way >> back. >> >> Expansion is triggered when an allocation attempt cannot be satisfied within >> the confines of the current user address space. Either because its too >> large, and/or the address space is too fragmented. But also if the user >> explicitly requests a mapping beyond the upper boundary of the current user >> address space. >> >> The latter is a problem, because we do exactly that, freely, during JVM >> setup. We probe the address space in various places: when allocating the >> heap, the class space, and when setting up the ZGC >> colored-pointer-address-format. In all these places, we assumed that probing >> has no adverse effect, because it has always been this way. But on s390 we >> can inadvertently upgrade the process page table layout to a higher level. >> >> A higher page table level will make every TLB miss a bit more expensive - >> longer latencies on memory access, and the larger page tables themselves >> also use more cache. A runtime like ours that does a lot of pointer hopping >> should really avoid expanding the page table unless we really really need >> that. We shouldn't unless we run with abnormally (TB-sized) heaps. >> >> ZGC setup is not a problem here, since it's unsupported on s390 (but >> something to keep in mind should we ever want to port it). But we need to >> fix heap reservation and class space reservation. >> >> ---- >> >> The patch: It fixes the reservation for s390. I was tempted to add the fix >> to a lower layer, e.g. to `os::attempt_reserve_memory_at`, but it feels >> wrong for lower layer APIs to be "too smart" - I want them to do exactly >> whats on the label - and because there are places where I *want* >> reservations to high addresses to go through, eg. for the experimental >> switches `SharedBaseAddress` and `CompressedClassSpaceBaseAddress`. >> >> CompressedClassPointersEncodingScheme.java needed fixing, too, since the >> upper limit of address space probing is now platform dependent. >> >> --- >> >> Tests: hotspot tier1 and gtests on s390 >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Thomas Stuefe has updated the pull request incrementally with one additional > commit since the last revision: > > off by 1 Retested the test on s390, linux x64 and MacOS aarch64, all green ------------- PR Comment: https://git.openjdk.org/jdk/pull/31990#issuecomment-5055323193
