RFR: 8243315: ParallelScavengeHeap::initialize() passes GenAlignment as page size to os::trace_page_sizes instead of actual page size

[Thomas Schatzl]

On Wed, 25 Nov 2020 15:52:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The model would be so much nicer if a `ReservedSpace` always just had one page-size.
>
> Yes, but I think it makes sense to allow the os layer to mix page sizes for large paged areas, for performance reasons. The fact that this coding exists, and that Intel wants to further complicate it and add 2M pages, means we have a need here. 
> 
> Trying to avoid this just means that people add patches sideways to satisfy specific needs, which hurts maintainability. Also, I don't like to discourage first time contributors with lots of concerns, therefore I'd like a cleaner, more flexible os layer.
> 
> But no-one forces you to accept multi-page-sized-areas. If you really want just one page size, you can query the largest page size available beforehand and align the reservation size accordingly, and with my proposed change you could now assert the result and log it correctly.
> 
> But if one just generally wants large pages without caring for the precise layout, one could let os::reserve_memory_special() do its best, and would now get the information about what reserve_memory_special() did. 
> 
> For example, were I to re-introduce large pages for Metaspace, I would like to have the luxury of just calling os::reserve_memory_special() without having to think about specific geometry - if the space is large enough for large pages, it should stitch the area together as best as it can.

Hi,

On 25.11.20 16:52, Thomas Stuefe wrote:
> Yes, but I think it makes sense to allow the os layer to mix page sizes 
> for large paged areas, for performance reasons. The fact that this 
> coding exists, 

That code may be an artifact of 32 bit machines from 10+ years ago where 
address space fragmentation has been a real concern (typically Windows). 
Or RAM sizes were measured in hundreds of MB instead of GBs where (on 
Linux) pre-reserving hundreds of MB for huge pages is/has been an issue.

> and that Intel wants to further complicate it and add 2M 
> pages, means we have a need here.

The JDK-8256155 (Intel) CR does not state that requirement. Imho it only 
says that the author wants to use (any and all) configured pages for 
different reserved spaces.

E.g. the machine has (on x64, to simplify the case) configured:

10 1G pages
1000 2M pages

so the heap should use the 1G pages (assuming it's less than 10G), other 
reservations like code heap should first use the 50 2M pages before 
falling back to other page sizes to better use available TLB cache entries.

I would prefer if we do not overcomplicate the requirements :) Also 
probably this should be asked and followed up in the correct review thread.

> Trying to avoid this just means that people add patches sideways to 
> satisfy specific needs, which hurts maintainability. Also, I don't like 
> to discourage first time contributors with lots of concerns, therefore 
> I'd like a cleaner, more flexible os layer.

I'd like a simpler, maybe less flexible but understandable by mere 
mortals OS layer :) lower layer that does not make upper layers too 
complicated.

> But no-one forces you to accept multi-page-sized-areas. If you really 
> want just one page size, you can query the largest page size available 
> beforehand and align the reservation size accordingly, and with my 

Which is no issue with 64 bit machines at all, but probably has been 
with the prevalence of 32 bit address spaces.

> proposed change you could now assert the result and log it correctly.
> 
> But if one just generally wants large pages without caring for the 
> precise layout, one could let os::reserve_memory_special() do its best, 
> and would now get the information about what reserve_memory_special() did.

This is a kind of one-sided argument, taking only commit into account. 
Since actually giving back memory is expected nowadays, taking care of 
different random page sizes is complicated.

E.g. when implementing G1's region memory management (in 8u40) the 
decision to only support a single page size for every one of its GC data 
structures has been a conscious one - because the complexity overhead 
did not justify the gains.

Nobody complained yet.

> For example, were I to re-introduce large pages for Metaspace, I would 
> like to have the luxury of just calling os::reserve_memory_special() 
> without having to think about specific geometry - if the space is large 
> enough for large pages, it should stitch the area together as best as it 
> can.

That's true, but that Metaspace layer then needs to be aware of multiple 
page sizes when uncommitting, and (presumably) tracking liveness on the 
lowest granularity anyway. Which does not make the code easier.

Thanks,
   Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/1161