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

[Coleen Phillimore]

On Mon, 29 Mar 2021 16:56:23 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

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

I deleted this branch by mistake, now restored. 
> 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.

I realize this.  It's just an attempt to allocate and it's designed to be used during a safepoint for only this allocation. I could change this to only call the non-TRAPS version of MethodCounters if we're at a safepoint?  Would that help?  Then the only time we'll miss out on metaspace counters periodically is if they were created to set breakpoints in a safepoint.

I'd hate for this special case to know more about metaspace, ala calling ClassLoaderMetaspace::expand_and_allocate.

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

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