RFR: 8264149 BreakpointInfo::set allocates metaspace object in VM thread

[Thomas Stuefe]

On Mon, 29 Mar 2021 13:24:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Looks good!
>> 
>> Thanks,
>> David
>
> Thanks David.  @tstuefe Can you review this?

Hi Coleen, 

GH swallowed my in code comment, so I repeat it here...

I'm not sure this is correct. Your new non-TRAPS Metaspace::allocate() would fail every time the GC threshold is touched. Where the old TRAPS version would break through the threshold and allocate successfully. 

CLMS->allocate() fails not only for "hard" OOMS, when we ran against MaxMetaspaceSize or CompressedClassSpaceSize, but also when we hit the GC threshold. `satisfy_failed_xxx` handles the latter case by increasing the threshold and retrying the allocation, in addition to scheduling a new GC maybe.

I guess the next "real" allocate, done with TRAPS, would then remove the blockage and increase the threshold and life goes on, but a number of metaspace allocations could have unnecessarily failed. This means that periodically we end up without profile counters on methods, and whatever the effect is of CLDG->had_metaspace_oom.

It looks like you could solve that by manually calling `ClassLoaderMetaspace::expand_and_allocate` after a failing `ClassLoaderMetaspace::allocate` in your non-TRAPS version. That may mean though that we miss out on GC possibilities, basically ignoring some instances of a triggered GC threshold without doing a GC.

Would be nice to simplify this. See also https://github.com/openjdk/jdk/pull/2289. This stuff is very complex.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/3207