"Nestegg" buffer for error reporting in native oom scenarios

[Thomas Stüfe]

p.s. this proposal is the most simple variant of the "pre-reserve a chunk
of memory for bad times" theme.

Alternative implementations could be to e.g. switch os::malloc() to a
preallocated buffer on OOM, but that would require to implement some sort
of free(), so one needs some sort of allocator atop of that buffer, however
primitive.

All doable, my proposal is just simpler.

Cheers, Thomas

On Wed, Jul 3, 2019 at 8:03 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:

> Hi,,
>
> I carry this tiny patch around since quite a while which makes error
> handling more stable in native OOM situations. I usually apply it when
> dealing with memory leaks, to increase the chance of useful error reports.
>
> A number of error reporting things require memory. When we are out of
> memory, those steps may fail.
>
> A prominent example is NMT: when creating a detailed report, it allocates
> memory. In OOM scenarios NMT will not work because of this, which is a pity
> since this is exactly the time where having an NMT report would be super
> useful.
>
> A clean solution would be to harden everything running inside error
> handling to work with pre-allocated buffers instead, or to not alloc memory
> at all. But that is difficult or even impossible.
>
> What I do instead is tp allocate memory at VM startup and to release it
> back into the clib when a native OOM happens (of course, only when the
> switch is set).
>
> This is of course no guarantee that this works - code running concurrently
> may gobble the memory up the moment I release it, for instance - but it
> works surprisingly often, and in a number of cases helped me e.g. to get a
> detailed NMT report where otherwise I would have gotten nothing.
>
> Patch:
>
>
> http://cr.openjdk.java.net/~stuefe/webrevs/nestegg/webrev.00/webrev/index.html
>
> What do you think? Too stupid or weird? We can talk of course about the
> naming :)
>
> I am not especially proud of that hack, but as a technique, it is at least
> dead simple and reasonably successful.
>
> Thanks, Thomas
>
>
>
>