On Thu, 4 May 2023 22:32:36 GMT, Coleen Phillimore <[email protected]> wrote:
> The ResourceHashtable conversion for JDK-8292741 didn't add the resizing
> code. The old hashtable code was tuned for resizing in anticipation of large
> hashtables for JVMTI tags. This patch ports over the old hashtable resizing
> code. It also adds a ResourceHashtable::put_fast() function that prepends to
> the bucket list, which is also reclaims the performance of the old hashtable
> for this test with 10M tags. The ResourceHashtable put function is really a
> put_if_absent. This can be cleaned up in a future change. Also, the remove
> function needed a lambda to destroy the WeakHandle, since resizing requires
> copying entries.
>
> Tested with JVMTI and JDI tests locally, and tier1-4 tests.
src/hotspot/share/utilities/resizeableResourceHash.hpp line 91:
> 89: // Calculate next "good" hashtable size based on requested count
> 90: int calculate_resize(bool use_large_table_sizes) const {
> 91: const int resize_factor = 2.0; // by how much we will resize
> using current number of entries
Nit: extra spaces brefore the '=' sign.
Q: Why is a FP constant assigned to the integer variable?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13818#discussion_r1185650312
