Fwd: Re: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support

[Jon Masamitsu]

Mikael,

Just a resend since I forgot the mailing list on my
reply.

Jon


-------- Original Message --------
Subject: 	Re: RFR 8056084: Refactor Hashtable to allow implementations 
without rehashing support
Date: 	Tue, 26 Aug 2014 13:45:14 -0700
From: 	Jon Masamitsu <jon.masamitsu at oracle.com>
To: 	Mikael Gerdin <mikael.gerdin at oracle.com>



http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/src/share/vm/utilities/hashtable.cpp.frames.html

On right side

372 #endif // SOLARIS || CHECK_UNHANDLED_OOPS

to

372 #endif CHECK_UNHANDLED_OOPS


Otherwise, looks good.

Reviewed.

Jon


On 08/26/2014 08:26 AM, Mikael Gerdin wrote:
> Hi all,
>
> For JDK-8048268 I need to do some refactoring of the Hashtable class template.
>
>  From the bug description:
> In order to simplify usage of the Hashtable<T, F> class the code to perform
> rehashing of the SymbolTable and StringTable should be factored out to an
> intermediate class common to those two tables.
> Also factor out HashtableEntry freelist allocation to allow implementors an
> easier route for providing their own memory management.
>
> Introducing the new intermediary superclass requires some calls to superclass
> functions to be qualified using the "this->" syntax due to the C++ template
> name lookup rules.
>
> a comment about hashtable.cpp RehashableHashtable::dump_table:
>
> -  int bucket_bytes = (int)num_buckets * sizeof(bucket(0));
> +  int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket<F>);
>
> I decided to change the sizeof to count the size of the hashtable bucket class
> instead of the HashtableEntry* returned by bucket(0), even though they may be
> of the same size currently.
>
> Note that the webrev url refers to another bug.
> Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/
> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084
>
> Testing: JPRT.
>