RFR: 8332455: Improve G1/ParallelGC tasks to not override array lengths

[Kim Barrett]

On Mon, 8 Jul 2024 16:04:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/arraySlicer.hpp line 74:
>> 
>>> 72: //    10 bits for slice: max 1024 blocks per array
>>> 73: //     5 bits for power: max 2^32 array
>>> 74: //    49 bits for   oop: max 512 TB of addressable space
>> 
>> This encoding is incompatible with Linux Large Virtual Address space:
>> https://www.kernel.org/doc/html/v5.8/arm64/memory.html
>> which has a 52 bit address space.  I also  don't know of any reason why future address space
>> configuration  couldn't support the full non-tagged range (so 56 bits). I think that makes this
>> scheme not viable.
>
> I think hardware support is an orthogonal issue. It would have been an issue if we just blindly casted the pointer to `oop`, and relied on hardware to only treat the lowest bits for the actual address and/or mmap-ed the Java heap at very high addresses.
> 
> But since we are masking out the `oop` explicitly (see `oop_extract_mask`) and we map Java heap at lower addresses (in first order, to please compressed oops), we do not care for practical heap sizes. What we get as the limit is how much of the Java heap we can represent, given that we encode `oop`-s. Shenandoah checks this on startup, for example: https://github.com/openjdk/jdk/blob/d8c1c6ab0543c986280dcfa1c6c79e010a7b35fb/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L202-L212

What is a practical heap size?  512T should be enough for everyone :)

As a former colleague liked to say, don't try to stuff two bits of information
into one bit of data.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19282#discussion_r1670215061