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

[Martin Doerr]

On Thu, 3 Nov 2022 22:09:21 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Filed 2 issues: https://bugs.openjdk.org/browse/JDK-8296336 https://bugs.openjdk.org/browse/JDK-8296334 Feel free to modify them.
> > I've added a check for metadata. I don't think we need to check for metadata relocations because the oop recorder always records all metadata pointers. We never iterate over the code to find metadata AFAIK (except for patching purposes, but the metadata is duplicated in this case, not in the code only). Please take a look.
> 
> The metadata in stubs might not have an oop. See the comment here:
> 
> https://github.com/openjdk/jdk/blob/054c23f484522881a0879176383d970a8de41201/src/hotspot/share/code/compiledMethod.cpp#L632

I think this code was written for x86 and is based on a wrong assumption. If a static call (or optimized virtual call) is reachable then the callee class can’t be dead. Unfortunately, JDK-8222841 didn’t include a test. I’ve removed the `CompiledMethod::cleanup_inline_caches_impl` change and ran a few tests like `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java`. Didn’t show errors.
Other platforms (e.g. PPC64, AArch64) do allocate a metadata slot via oop recorder. The code you are referring to only clears the slot in the metadata section, not the replicated value which is actually used by the code. Note that `fix_metadata_relocation()` does nothing on most platforms! This is a further indication that the code is not needed.
Should I file another RFE for that?

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

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