RFR: 8369219: JNI::RegisterNatives causes a memory leak in CodeCache [v4]
    Francesco Andreuzzi 
    fandreuzzi at openjdk.org
       
    Sat Oct 18 10:16:02 UTC 2025
    
    
  
On Thu, 16 Oct 2025 23:40:08 GMT, Dean Long <dlong at openjdk.org> wrote:
>>> We could instead allow them to be cleaned up like regular nmethods.
>> 
>> That sounds reasonable to me, native methods seem to be tracked like all other nmethods. 
>> 
>> Removing `is_native_method()` altogether from the condition was the first implementation I had, and as far as I remember there was no failure in tier1 or tier2. Should I propose this alternative implementation as part of this PR?
>
> I am tempted to say yes, for consistency, but it probably won't make much of a difference either way.  But now I am wondering, if these cold native wrappers continue to be immortal, then do they really need to give them nmethod entry barriers?  Removing the barrier could remove some overhead.  Whatever direction we decide to go, it would be good to add a comment here explaining the decision and/or trade-offs.
Is it actually possible to remove entry barriers for _any_ garbage collectible nmethod? How can we know an nmethod is not used anymore, even when it is made not entrant? `is_cold()` bails out when an nmethod does not support entry barriers:
// On platforms that don't support nmethod entry barriers, we can't
// trust the temporal aspect of the gc epochs. So we can't detect
// cold nmethods on such platforms.
So, the decision of removing entry barriers for native nmethods would make the memory leak I'm trying to fix here effectively unfixable? Let me know if I'm missing something.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27742#discussion_r2442009918
    
    
More information about the hotspot-compiler-dev
mailing list