RFR: 8301684: Fix test code to not get finalizer deprecation warnings

[David Holmes]

On Fri, 10 Mar 2023 08:23:45 GMT, Afshin Zafari <duke at openjdk.org> wrote:

> To replace the finalizer use in the code, the `Cleaner` approach is used as stated in [Oracle doc on deprecated finalize() method](https://docs.oracle.com/javase/10/docs/api/java/lang/Object.html#finalize()).
> Briefly:
> 1.  An instance of `Cleaner` (`java.lang.ref`) is created.
> 2. Using the `Cleaner`, an object is registered with a `Runnable` callback that is notified when the object is no longer reachable (GC'ed).
> 3. Write code in the callback to do other cleanings.
> 4. Or, use the `Cleanable` object which is returned from registration above and call its `clean` method to explicitly clean the object.
> 
> 
> Cleaner c = new Cleaner();
> Cleanable cleanable = c.register(an_obj, a_runnable);
> ...
>   //JVM notifies by calling the 
>     a_runnable.run() {...}
> ... 
> // possible to explicit cleaning 
> cleanable.clean(an_obj); 
> 
> ### Tests
> local: vmTestbase/nsk/monitoring/stress/classload
> mach5: tier 1-5

This does not look quite right me - see comments below. You need to know that the Custom loader has become unreachable and only then check the unloaded classes.

There are numerous references to finalization still in the code that should be updated to a more suitable form.

I think things can be simplified/streamlined somewhat.

Thanks

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 123:

> 121:      * The cleaner instance whose run() will be called by JVM.
> 122:      */
> 123:     private CustomClassLoaderCleaner customCleaner;

Not clear you actually need to store this, or cleaner or cleanable. The cleaner registration can just use locally defined objects.

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 126:

> 124: 
> 125:     /**
> 126:      * The java.lanf.ref.Cleaner object for registering the cleaner and the object to be traced.

typo: lanf

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 357:

> 355:         GarbageUtils.eatMemory(stresser, 50, 1024, 2);
> 356:         if (cleanable != null) {
> 357:           cleanable.clean();

This is wrong. You want the GC to cause the Cleaner to be processed indicating that the CustomClassLoader (and hence the classes it loaded) is actually unreachable and so the classes can be unloaded.

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

Changes requested by dholmes (Reviewer).

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