RFR: 8301136: Improve unlink() and unlink_all() of ResourceHashtableBase [v5]

[Ioi Lam]

On Fri, 27 Jan 2023 23:16:52 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> 1. Apply the same idea of JDK-8300184 to unlink().
>> 2. Because ResourceHashtableBase doesn't support copy assignment, client of it has to purge all elements first when it needs to assign it. We would like provide a specialized version called 'unlink_all()'.  We don't need to update each node's _next in this case. We only nullify all buckets. 
>> 3. This patch also provides a specialized version of unlink_all() for destructor. We don't even update buckets. it's dead anyway.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add lambda API unlink(Function f) per reviewers' request.

I've looked at the last version ([086750e](https://github.com/openjdk/jdk/pull/12213/commits/086750e46a4abb7115c2ff0ea49801c17df3981e)) in detail and I can understand why your implementation for `unlink` is so much more complex than `iterate`. The fundamental reason is sometimes we allow special clean up of the value (the old `unlink` API), while other times we don't (the destructor, and the new `iterate_all` API).

I think we need to rewrite ResourceHashtable to allow automatic and safe disposal of both the keys and the values. I've filed [JDK-8301296](https://bugs.openjdk.org/browse/JDK-8301296).

I would suggest putting this PR on hold until we come up with a new design that addresses the above issue.

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

PR: https://git.openjdk.org/jdk/pull/12213