RFR: 8279949: JavaThread::_free_handle_block leaks native memory

[David Holmes]

On Sun, 13 Feb 2022 19:07:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Sorry Leonid,
>> 
>> I think we need to understand exactly how we end up with a chain of blocks at thread exit - see comment below.
>> 
>> David
>
>>  think we need to understand exactly how we end up with a chain of blocks at thread exit 
> 
> My understanding is `JNIHandleBlock` is allocated on every upcall from VM to Java code (it's part of `JavaCallWrapper` ctor). Since it is possible to have "nested" upcalls (Java -> VM -> Java -> VM), there are multiple thread-local blocks allocated and they eventually end up on the free list.

@iwanowww  Right for the free-list case this is expected if there are nested upcalls. So that is normal - my mistake for thinking it needed unbalanced use. So happy to see that free-list get recursively deleted.

But still concerned there may be some unexpected interaction with pop_frame_link when the active-list is cleared.

Simplest solution would be to introduce a new method that clears recursively and use that for the free-list case. Still leaves unanswered questions about the active-list, but wouldn't change any behaviour there.

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

PR: https://git.openjdk.java.net/jdk/pull/7453