RFR: 8291969: Convert LoaderConstraintsTable to ResourceHashtable [v4]

[David Holmes]

On Fri, 19 Aug 2022 19:16:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This converts the LoaderConstraintTable to ResourceHashtable.  It's a bit different than the other conversions in that the LoaderConstraintEntry has to be restructured to hold all the loader constraints for that class name, since the search key is the class name.  Also, I replaced the raw arrays with GrowableArray, because it's less code.
>> Tested with tier1-3, and tier 4-7 previously with other changes.  I also verified code paths with some temporary asserts with existing tests, including jck tests.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename LoaderConstraintEntry, which isn't a loader constraint, to ClassNameEntry.

src/hotspot/share/classfile/loaderConstraints.cpp line 79:

> 77: 
> 78: // For this class name, these are the LoaderConstraints for classes loaded with this name.
> 79: class ClassNameEntry {                               // copied into hashtable as value

I find the naming for these map/table entries very awkward in general. A Map is a mapping from keytype K to a value type V. Here K ==  Symbol* (a class name), and V == a set of LoaderConstraints

src/hotspot/share/classfile/loaderConstraints.cpp line 170:

> 168:   // class that is eventually loaded must match between these two loaders.
> 169:   bool created;
> 170:   ClassNameEntry* entry = _loader_constraint_table.put_if_absent(name, &created);

Is this "empty" entry visible before we get to call initialize on it below? Why do we not construct the entry properly before adding it? Do we really expect concurrent additions in this case?

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

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