"Nestegg" buffer for error reporting in native oom scenarios

David Holmes david.holmes at oracle.com
Wed Jul 3 23:58:22 UTC 2019


Hi Thomas,

On 4/07/2019 4:03 am, Thomas Stüfe 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.

Basic approach seems okay, but I don't like some of the details ie the 
need to expose this in the OS API. but I'm into my last 2 days before 2 
weeks vacation and don't have time to get into it at this stage - sorry. 
(BTW a lot of folk are on vacation, or going on vacation this month.)

Also pet peeve: p_foo  - we don't use hungarian notation in the VM so 
the p_ should be dropped. ;-)

Cheers,
David
-----

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


More information about the hotspot-runtime-dev mailing list