RFR: 8301403: Eliminate memory allocations in JVMFlag::printFlags during signal handling [v3]

[Thomas Stuefe]

On Thu, 18 Jul 2024 05:50:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I still dislike the misuse of the enum. Among other things, this is not threadsafe,
> 
> I was under the impression the rest of the flag bits were immutable, hence no actual thread-safety issue for hs_err reporting. But yes in general this does make printFlags not-thread-safe. Your alternative bitmap design sounds reasonable.
> 
> > Nobody talks about removing the decoder; I meant removing malloc from the decoder.
> 
> I was under the impression that would be very difficult to do (not that I've looked into it) - hence the acceptance of its use. A malloc-less decoder doesn't sound trivial.

A very simple idea could be to pre-allocate a "memory balloon" at the start of the JVM and use that one up at hs-err time. Possibly optionally, depending on how large the balloon is. But some dozen KB probably would not hurt in any case, and may solve the majority of malloc deadlocks we see in hs-err such that the remaining cases are so super rare that we don't care.

Done smartly, one would integrate this somehow into os::malloc such that, at the beginning of error reporting, we switch over to "balloon use" and use that one up until either error handling is done or the balloon is gone. The nice thing about this would be that it would work for every component.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20202#issuecomment-2235701235