On Mon, 22 Mar 2021 22:48:05 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> From CR: >> The useful/general BasicHashtable uses a block allocation scheme to >> reportedly reduce fragmentation. When the StringTable and SymbolTable used >> to use this hashtable, performance benefits were reportedly observed because >> of the block allocation scheme. Since these tables were moved to the >> concurrent hashtables, the tables left that use the block allocation scheme >> are: >> >> AdapterHandlerLibrary, ResolutionError, LoaderConstraints, Leak profiler >> bitset table and Placeholders. 3 of these tables are very small and never >> needed block allocation to prevent fragmentation at least. Also there are 3 >> KVHashtables, which are built from BasicHashtable. 2 are used during dumping >> and 1 is ID2KlassTable which appears small. >> >> ModuleEntry, PackageEntry, Dictionary, G1RootSet for nmethods, and >> JvmtiTagMap tables didn't use the block allocation scheme. >> >> Removing this removes 7 pointers per table, and for each ClassLoaderData, >> which has 3 tables, removes 21 pointers. >> >> This change was performance tested on linux and windows. >> >> It was also tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Fix Hashtable constructor and comments. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3123
