Unconditional messages on large page reservation errors
Thomas Schatzl
thomas.schatzl at oracle.com
Thu May 6 09:34:14 UTC 2021
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
More information about the hotspot-gc-dev
mailing list