Unconditional messages on large page reservation errors

[Stefan Johansson]

We had some internal discussions touching this area. Mostly that the 
logging/warnings for large page reservation failures differ depending on 
OS and the logging is using multiple tags. I have filed an issue for this:
https://bugs.openjdk.java.net/browse/JDK-8266624

This could also include turning warning() into log_warning() to allow 
better control over the output.

Cheers,
Stefan

On 2021-05-06 11:34, Thomas Schatzl wrote:
> Hi,
> 
> On 24.04.21 14:31, Stefan Johansson wrote:
>> Hi Thomas,
>>
>> Sorry for the late reply.
>>
>> On 2021-04-17 06:11, Thomas Stüfe wrote:
>>> Hi all,
>>>
> [...]
>>
>>>
>>> Large page reservations may fail at any time 
>>> os::reserve_memory_special()
>>> function is called, e.g. because the large page pool is temporarily
>>> exhausted. And os::reserve_memory_special() is a general purpose 
>>> function, not only used for the heap. Running out of large pages is 
>>> not fatal, since the caller can just fall back to normal page 
>>> allocation. Which is what we
>>> do when reserving the java heap. I think unconditional printouts should
>>> only happen in case of fatal errors, when the VM is about to die.
>>>
>>
>> I don't really agree here since the performance implications of not 
>> using large pages are quite big. I think it is fair to issue the 
>> warning since in most cases it signals that there is an environment 
>> configuration problem. For testing we have the possibility to use 
>> -XX:-PrintWarnings and I saw you used that to fix the issue mentioned 
>> above.
>>
>> Also, what would the use-case for warning() be if not for printing 
>> information in non-fatal but problematic situations (which I think 
>> this is).
> 
> I agree with Stefan here - the performance implications are too big in 
> some cases (e.g. in the Java heap case 10-15+%) to just ignore. I also 
> agree that the main case for these warnings are typically unintentional 
> misconfigurations, so a warning would be appropriate imho.
> 
> For fatal issues there is already fatal(), so using warning() for the 
> same case does not make sense to me either.
> 
>>
>>> The unconditional warning probably made sense in the context of 
>>> reserving
>>> the java heap, if the user explicitly specified UseLargePages. I 
>>> propose to
>>> change this to either
>>> - if large page allocation for the heap fails, trace with info level
>>> and fall back to small pages. Leave it up to the user to increase UL and
>>> monitor log output to find out about this. This is what we usually do 
>>> when
>>> system APIs fail.
>>> - continue printing the message with error level, but exit the VM. If
>>> it's serious enough to unconditionally notify the user, it's serious 
>>> enough
>>> to stop the VM.
>>>
>>> I prefer the former. What do you think?
>>
>> As I said above, I see a value in warning if you don't get what you 
>> are requesting. But I know others that think exiting is a better 
>> strategy. If I'm not mistaken ZGC won't start if it can't reserve 
>> enough large pages. One thing that I would like to change in this are 
>> is for these warnings to be converted to use UL. That way we could 
>> turn of warnings on a much finer granularity and we wouldn't have to 
>> use jio_snprintf to compose messages.
>>
> 
> Agree with Stefan here as well, depending on the implementation a more 
> granular approach to these warnings may allow ignoring of particular 
> warnings if the user wants.
> 
> Thanks,
>    Thomas