JDK-8289632 : Codeblob leaks name if installed via JVMCI CodeInstaller
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,19,20
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-07-03
  • Updated: 2022-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8289633 - Forbid raw C-heap allocation functions in hotspot and fix findings
Description
Found while I worked on JDK-8289633.

JVMCI CodeInstaller strdup's the name before creating the codeblob in CodeInstaller::install(). Note that it uses raw strdup instead of os::strdup, which is why this does not show up in NMT. But ~CodeBlob does not release the name.

AFAICS all other places where code blobs are created are using static strings.
Comments
Should we close this as Not An Issue then? Even for C2, we never delete RuntimeStubs AFAIK.
24-10-2022
The comment for the `RuntimeStub::operator delete` declaration in codeBlob.hpp is what I'm basing my assumption on. That and the fact there's no definition of this method in codeBlob.cpp. Note that this only applies to Graal generated stubs. Normal Graal generated nmethods are subject to deletion just like all other nmethods.
06-07-2022
Cleanup is not necessary, since JDK-8289633 it has been changed to use os::strdup. Wrt to RuntimeStubs never been deleted, I am not sure but if Douglas is sure that is fine for me. So, graal never deletes generated code? And that code can never get pushed out of the code heap, e.g. by recompilation? I am not a JVMCI expert. Well. Now its instrumented at least, since we use os::strdup, so it will show up in NMT as a leak if we leak. E.g. run a JVMCI test with -XX:PrintNMTStatistics and check if at shutdown we have many outstanding allocations from that site.
06-07-2022
Thanks Doug for taking a look at this! [~stuefe] can you confirm this? If so we could turn this into a cleanup RFE given that it's better to use os::strdup instead of raw strdup.
06-07-2022
I don't think this is a bug as RuntimeStubs are never deleted as far as I can see[1] and the strdup is only done when installing a JVMCI generated RuntimeStub. [1] https://github.com/openjdk/jdk/blob/aa2fc54b61ad84cc6faa80efa3bd3097adbbc422/src/hotspot/share/code/codeBlob.hpp#L509-L512
05-07-2022
Hi [~dnsimon], can you take a look at it?
05-07-2022
ILW = Leaking name when using JVMCI CodeInstaller, only with JVMCI, no workaround = MMH = P3
05-07-2022