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

[Thomas Stuefe]

On Mon, 29 Mar 2021 04:59:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It can't work from the VMThread.   Patricio and I were chatting yesterday and he pointed out neither of these VM operations can nest (VM_ChangeBreakpoints and VM_MetaspaceGC) making up names but you get the point.
>
> Okay.

Are you sure?

This means that calls to your new non-TRAPS Metaspace::allocate() fail every time the GC threshold is touched. Since CLMS->allocate() fails not only for "hard" OOMS, when we ran against a hard limit, but also when we hit the GC threshold. satisfy_failed_xxx handles both cases; in the latter case specifically it increases the threshold and retries the allocation.

I guess the next "real" allocate, one done with TRAPS, would then remove the blockage and increase the threshold and life goes on, but meanwhile a number of metaspace allocations could have unnecessarily failed.

It looks like you could solve that by manually calling `ClassLoaderMetaspace::expand_and_allocate` after a failing allocate in your non-TRAPS version; but I'm not completely sure that is right either, since it would mean we miss one GC opportunity.

This stuff feels way too complex.

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

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