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

Wed Apr 22 07:38:50 UTC 2020


On 2020-04-21 22:07, Bernd Eckenfels wrote:
> Thanks Stefan, was looking for the candidate page sizes not the picked ones, but this logging tag is already a good start for some experiments.
Yes, adding such logging with that tag might make sense.

> 
> Interesting that so many areas use the 4K pages despite the minimum size above 2mb, I guess this is due to the 8-divisor used in other places as well, I am glad it could be removed for the heap.
Yes, most likely.

> 
> The generation alignment (and the mentioned logging irregularity) seems to come from the align_up call, I am not sure if this should actually work on the page size and not on the overall size.
The generation alignment does not have to be a page size, but should be 
aligned to it. I filed JDK-8243315 to look at this.

Stefan

> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Stefan Johansson <stefan.johansson at oracle.com>
> Gesendet: Tuesday, April 21, 2020 9:41:41 PM
> An: Bernd Eckenfels <ecki at zusammenkunft.net>; hotspot-gc-dev at openjdk.java.net <hotspot-gc-dev at openjdk.java.net>
> Betreff: Re: RFR(S): 8209162: Page size selection does not always select optimal page size
> 
> Hi Bernd,
> 
> Not sure this is exactly what your after, but we have the log-tag
> pagesize. For Parallel you get this:
> java -Xlog:pagesize -XX:+UseParallelGC -version
> [0.002s][info][pagesize] CodeHeap 'non-nmethods':  min=2496K max=7428K
> base=0x00007f6ae8ceb000 page_size=4K size=7428K
> [0.002s][info][pagesize] CodeHeap 'profiled nmethods':  min=2496K
> max=119164K base=0x00007f6ae942c000 page_size=4K size=119164K
> [0.002s][info][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K
> max=119168K base=0x00007f6af088b000 page_size=4K size=119168K
> [0.003s][info][pagesize] Heap:  min=8M max=8028M base=0x000000060a400000
> page_size=512K size=8028M
> [0.003s][info][pagesize] Card Table:  min=16441345B max=16441345B
> base=0x00007f6ae7d3c000 page_size=4K size=16060K
> [0.004s][info][pagesize] Mark Bitmap:  min=256896K max=256896K
> base=0x00007f6ad825c000 page_size=4K size=256896K
> [0.004s][info][pagesize] Parallel Compact Data:  min=642240B max=642240B
> base=0x00007f6b043b2000 page_size=4K size=628K
> [0.004s][info][pagesize] Parallel Compact Data:  min=16056K max=16056K
> base=0x00007f6ad72ae000 page_size=4K size=16056K
> java version "15-internal" 2020-09-15
> Java(TM) SE Runtime Environment (build
> 15-internal+0-2020-04-21-1230537.sjohanss...)
> Java HotSpot(TM) 64-Bit Server VM (build
> 15-internal+0-2020-04-21-1230537.sjohanss..., mixed mode, sharing)
> 
> And if you run it with larger page enabled:
> java -Xlog:pagesize -XX:+UseParallelGC -XX:+UseLargePages -version
> [0.004s][info][pagesize] CodeHeap 'non-nmethods':  min=2496K max=8M
> base=0x00007f1d00c00000 page_size=4K size=8M
> [0.004s][info][pagesize] CodeHeap 'profiled nmethods':  min=2496K
> max=116M base=0x00007f1d01400000 page_size=4K size=116M
> [0.004s][info][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K
> max=116M base=0x00007f1d08800000 page_size=4K size=116M
> [0.005s][info][pagesize] Heap:  min=8M max=8028M base=0x000000060a400000
> page_size=2M size=8028M
> [0.005s][info][pagesize] Card Table:  min=16441345B max=16441345B
> base=0x00007f1d1cba6000 page_size=4K size=16060K
> [0.007s][info][pagesize] Mark Bitmap:  min=256896K max=256896K
> base=0x00007f1cf1120000 page_size=4K size=256896K
> [0.007s][info][pagesize] Parallel Compact Data:  min=642240B max=642240B
> base=0x00007f1d1c094000 page_size=4K size=628K
> [0.007s][info][pagesize] Parallel Compact Data:  min=16056K max=16056K
> base=0x00007f1cf0172000 page_size=4K size=16056K
> java version "15-internal" 2020-09-15
> Java(TM) SE Runtime Environment (build
> 15-internal+0-2020-04-21-1230537.sjohanss...)
> Java HotSpot(TM) 64-Bit Server VM (build
> 15-internal+0-2020-04-21-1230537.sjohanss..., mixed mode, sharing)
> 
> Looks like we have a bug here, when not running with large pages the
> reported heap size for the heap is 512k which is not the page size, but
> the generation alignment.
> 
> Hope this helps,
> Stefan
> 
> On 2020-04-21 20:11, Bernd Eckenfels wrote:
>> 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
>>