RFR: 8279949: JavaThread::_free_handle_block leaks native memory

[Leonid Mesnik]

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

I agree that JNIHandleBlocks are a little bit unclear and might need some explanation.

The active_list is organized as list of lists of JNIHandleBlocks:
block->_next->_next....
|
_pop_frame_link
|
block->_next->_next...

so the only fist block could have non-NULL _pop_frame_link and refer to the first block in the list. See class JNIHandleBlock

  // The following instance variables are only used by the first block in a chain.
  // Having two types of blocks complicates the code and the space overhead in negligible.
  JNIHandleBlock* _last;                        // Last block in use
  JNIHandleBlock* _pop_frame_link;              // Block to restore on PopLocalFrame call
  uintptr_t*      _free_list;                   // Handle free list


The function  release_block() deletes (or return to _free_handle_block) the list block->_next->_next.. and recursively calls itself for next frame. 

The  JNIHandleBlock referred with _next never might be referred with  _pop_frame_link  and cloud be safely deleted. My assertion just check that only first block refer to other frame.

It might be simpler to have
JNIHandleBlockFrame which is list of JNIHandleBlock and also have a pointer _pop_frame_link to other chain to avoid mess with _next and _pop_frame_link pointers.

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

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