On Mon, 22 Mar 2021 15:49:24 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. I forgot to add that we can eventually replace these tables with std::unordered_set once the allocation and other template parameters are decided on. There are also other cleanups that we could do with this code, ie. Hashtable isn't that different from BasicHashtable so really isn't needed. We could make the Entry type a template parameter. This change is only a step in this direction. ------------- PR: https://git.openjdk.java.net/jdk/pull/3123
