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

[Stefan Johansson]

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,
>>>
>>> On 21.04.20 13:18, Stefan Johansson wrote:
>>>> Hi Ivan,
>>>>
>>>> I'm not very familiar with this code, but one observation. This is a 
>>>> bit similar to what I looked at recently for G1. There the region 
>>>> size was different for a given heap size depending on if Xms was set 
>>>> or not. Here we can run into a situation where the page size differ 
>>>> depending on Xms, and this also feels a bit strange. Would there be 
>>>> a problem to simplify this to a single line and always just care 
>>>> about min:
>>>> const size_t page_sz = os::page_size_for_region_aligned(MinHeapSize, 
>>>> 4);
>>>>
>>>> I'm trying to understand when this would be a problem, but can't 
>>>> think of anything straight away.
>>>>
>>>
>>>    the RFE is a suggestion to maximize page sizes when Xms == Xmx. 
>>> I.e. if you do that, you do not care about uncommitting memory, so 
>>> there is no need for being able to uncommit. In this case it is 
>>> favorable to use maximum page size for throughput.
>>
>> I agree with that, and only looking at MinHeapSize will achieve that, 
>> since for a fixed heap it is the same as MaxHeapSize. I'm just trying 
>> to come up with a case where the min-calculation leads to using a 
>> larger page size than we want so that we need to do the max/8 
>> calculation. Something like:
>> -Xmx10m -Xms8m => 4k pages because 10/8 is below 2mb, while 8/4 == 
>> 2mb. Why is this good? I guess it might be good if -Xmx was 9m, but in 
>> such case, wouldn't some other alignment step in and prevent us from 
>> using 2mb pages?
> 
> The VM will be limited in the amount of uncommit possible if MaxHeapSize 
> is "close" to MinHeapSize.
> 
> E.g. Xms = 4gb and Xmx = 6gb will only allow 4, 5, or 6 GB of committed 
> memory when using 1 GB pages. This might be limiting the possible 
> committed heap sizes too much, giving "VM never uncommits memory" reports.
> 
> 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?

Cheers,
Stefan

> 
> Thanks,
>    Thomas