Unconditional messages on large page reservation errors

[Thomas Stüfe]

Hi guys,

sorry for the late response.

I can see your points for the heap, which is typically huge and allocated
up front, so these messages are visible right away.

I was mostly thinking of non-heap use cases, with reservations which happen
sporadically during the lifetime of a VM.

With JEP387 we disabled large pages for Metaspace but I plan to re-enable
this feature again. In that case we would have periodic reservations of
metaspace, and this is a case where I would not like to see sporadic
unconditional error messages.

But I can live with log_warning for now. At least it would be consistently
controllable.

Cheers, Thomas


On Thu, May 6, 2021 at 11:49 AM Stefan Johansson <
stefan.johansson at oracle.com> wrote:

> 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
>