RFR: 8295724: VirtualMachineError: Out of space in CodeCache for method handle intrinsic

[Martin Doerr]

On Wed, 2 Nov 2022 18:22:25 GMT, Dean Long <dlong at openjdk.org> wrote:

> I'm not sure this change is safe. We never put nmethods into NonNMethod (see code_blob_type_accepts_nmethod() and CodeCache::is_non_nmethod()). If we did, a lot of things could break, because NMethodIterator doesn't look in that heap for nmethods. We might get away with it if method handle intrinsics don't have oops or inline caches, but it seems dangerous. Also, this change only makes the failure harder to reproduce. We could still run out of NonNMethod space, right?

I think the method handle intrinsics were just implemented as nmethods because it was easy to do. They just perform method handle dispatch and contain no immediate oops. They are more like stubs (and like the interpreter versions which aren't nmethods, either). So, I can't see what could break by treating them this way.
To your 2nd question: No, we can't just fall back to using interpreter entries when calling from compiled code. The calling convention is not compatible.
We could get out of space in the NonNMethod segment, too, but the GC has more time until then. I have thought about waiting for the GC, but how long should we wait? A complete marking cycle of a huge Java heap may take time. Terminating the VM may still be undesired, but an unresponsive application, too. The situation sounds similar to "GC overhead limit exceeded".

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

PR: https://git.openjdk.org/jdk/pull/10933