RFR: 8292916: Streamline LoaderConstraint purging

[David Holmes]

On Thu, 25 Aug 2022 12:56:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The code to purge loader constraints walks through the class loader list of an unloaded class, and then asserts that the there are no leftovers. It can just directly remove the list of loaders without that walk.
> 
> Also I left the variable name 'probe' to help with diffs for [JDK-8291969](https://bugs.openjdk.org/browse/JDK-8291969) a little, but it's a bad variable name.
> 
> Tested with tier1-3 which contains jck tests.

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

> 104:   }
> 105: 
> 106:   void remove_constraint(Symbol* name, LoaderConstraint* constraint) {

It seems wrong to pass in the name just so you can use it in a logging statement. Makes me think that `ConstraintSet` should also store the name for which it is a set of Constraints.

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

> 199:         if (lt.is_enabled()) {
> 200:           ResourceMark rm;
> 201:           lt.print("purging class object from constraint for name %s,"

You are doing more than just purging the class object now.

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

> 211:         // The class is alive or null but some of of the loaders may not be.
> 212:         // Remove entries no longer alive from loader array
> 213:         for (int n = constraint->num_loaders() - 1; n >= 0; n--) {

I'm curious why we iterate backwards here?

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

> 232:         }
> 233:         // Check whether the set should be purged
> 234:         // Only one loader doesn't enforce a constraint.

So just to be clear, if we then have a second loader for a class of this name, then that would cause a constraint to be recreated, which would include both loaders?

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

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