On Thu, 19 Jun 2025 06:33:08 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add a basic gtest. > > I feel apprehensive about this; the solution feels pretty complex and I am > not fully convinced this is the simplest solution for this problem. > > How much space to we lose in real life? Side note: I see the payload of the > jmethodID block in NMT is allocated with mtInternal, so we don't see it in > NMT. We should add jmethodIDs as an own category to NMT. > > A pragmatic alternative solution could be to do delete them, but delayed: > keep the last N methodblocks undeleted. It is rare that JNI accesses > jmethodIDs long after they have been deleted. Typically, the bad access > happens close after class unloading, e.g. because of concurrency problems in > customer code. > > We could then make the parameter N configurable, and thus give customers and > supporters a tool to check for these kind of errors. > > (I briefly wondered whether we could just mmap these blocks, and > uncommit/mprotect them on release, so that we stop paying the memory costs > but don't release the address space; but the coarser page size allocation > granularity would make this probably forbidding in terms of mem cost per > class) @tstuefe, so at the moment we maintain safety for use-after-unload but at the expense of storage. Coleen's proposal maintains the same level of safety but reclaims the storage. You are suggesting a "simpler" technique to reclaim the storage by reducing the level of safety. I'd prefer to not re-open the door to unsafe usage, no matter how unlikely it may be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2986841710
