RFR: 8310428: Add CollectedHeap::reserved_range() API to return reserved heap memory range

[Thomas Stuefe]

On Wed, 21 Jun 2023 15:30:17 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to add a new API `CollectedHeap::reserved_range()`. The changes are extracted out from https://github.com/openjdk/jdk/pull/14520 as per the suggestion [here](https://github.com/openjdk/jdk/pull/14520#discussion_r1234991165). Support for ZGC is not implemented yet as it can have discontiguous heap regions and unlike other collectors, it does not set `CollectedHeap::_reserved`.

> I've had an off-line discussion with @fisk and created an investigative RFE based on his ideas. Please see #14520 and use that PR for further discussion on this topic.

Please let's have the discussion in the open.

Nobody answered me, but I repeat, there is merit in knowing the contiguous region for collectors that have a contiguous reserved region. I don't understand why we have to treat developers like children and force them to use really bad workarounds.

Just an example of the weird complexity this API omission causes. See class space reservation, where we try to reserve class space adjacent to the java heap: https://github.com/openjdk/jdk/blob/bfcca5eff96ac3cd72996b6c4865872c2da4de53/src/hotspot/share/memory/metaspace.cpp#L794-L796.

1) we don't know the address range of the heap
2) so we have to misuse CompressedOops::encoding_range, which is a bad fit. Encoding range is not heap range. It can (often does) start before the heap, so we don't know the heap start address. It only tells us the heap range end, but that is an accident of implementation: semantically, it is incorrect since the encoding range end is not the end of the heap.
3) Since we don't get the start address, we only know heap range end. That forces us to reserve the class space adjacent - following - the heap range.
4) So, for zero-based heap reservation, we have to leave a (potentially very large - 1G) gap between zero-based encoding range end and the heap end: https://github.com/openjdk/jdk/blob/bfcca5eff96ac3cd72996b6c4865872c2da4de53/src/hotspot/share/memory/virtualspace.cpp#L548-L558 This is bad, since it reduces the chance of getting zero-based heap. It also means we need to code intimate knowledge about class space (e.g. class space size) at heap reservation. Heap reservation should not have to know these things.
5) if, instead, we had known the start address of the heap at (4), we could just reserve the class space in front to it. There would have to be no need for leaving a large gap between zero-based compressed oops encoding range end and heap end. Also, we would not need to have class-space knowledge at heap reservation.

And all this complexity for a scenario that is not even supported on ZGC (CompressedOops) !

This is suboptimal. With a simple "CollectedHeap::reserved_range()" in combination with "CollectedHeap::is_contiguous()", this could be solved in about 10 lines of code.

So,no, I don't think this discussion has come to a satisfying close.

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

PR Comment: https://git.openjdk.org/jdk/pull/14595#issuecomment-1604898333