RFR(S): 8209162: Page size selection does not always select optimal page size

[Bernd Eckenfels]

Related question is there a good way to list in a production JVM what page sizes it has discovered on a specific platform? And has somebody a list of all (supported) platforms (and which page sizes depend on what additional condition).

I wonder if the divisor of 8 (instead of 4) makes any positive change. For that the typical page sizes would be interesting. This 8 is used in quite a few places, maybe a "regionsize_alignedforgrowth()" would be a way to centralize this?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: hotspot-gc-dev <hotspot-gc-dev-bounces at openjdk.java.net> im Auftrag von Ivan Walulya <ivan.walulya at oracle.com>
Gesendet: Dienstag, April 21, 2020 7:51 PM
An: Thomas Schatzl
Cc: hotspot-gc-dev
Betreff: Re: RFR(S): 8209162: Page size selection does not always select optimal page size

Please find new webrev

https://cr.openjdk.java.net/~iwalulya/8209162/02/

//Ivan

> On 21 Apr 2020, at 17:11, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On 21.04.20 14:59, Stefan Johansson wrote:
>> On 2020-04-21 14:44, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On 21.04.20 14:28, Stefan Johansson wrote:
>>>>
>>>>
>>>> On 2020-04-21 13:22, Thomas Schatzl wrote:
>>>>> Hi,
> [...]
>>>
>>> Then again, this is parallel gc we are talking about which you likely want to run with -Xms==-Xmx.
>>>
>>> The "4" and "8" constants in the code are "random" numbers.
>> Yeah, the scenarios where the 8 help feels very limited and constructed. I would argue that a 1GB granularity would be a bit much even if the heap is 10g.
>> In cases where 1g pages are configured I would imagine that the heap sizes used are a lot bigger than this. Kind of like for 2mb page, if it works sub-optimal for 10mb heaps, I'm fine with that.
>> So are you ok skipping the 8 and just going for not as random 4?
>
> That's fine with me. We can change it again.
>
> Thomas