RFR: 8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output"

[Brent Christian]

On Fri, 21 Mar 2025 14:24:13 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up the intermittent failures:
>> 
>> * run with `othervm`: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test's `finalize()` method
>> * The test uses `volatile` ints, but sets them based on their current value, which is not reliable; convert to `AtomicInteger`
>> * use `PhantomReference`s to ensure that at least two `MyObject`s have become unreachable. If one is stuck in `finalize()`, at least one is still waiting to be finalized and should show up in the histogram.
>
> test/jdk/java/lang/ref/FinalizerHistogramTest.java line 38:
> 
>> 36:  * @modules java.base/java.lang.ref:open
>> 37:  * @library /test/lib
>> 38:  * @build jdk.test.lib.util.ForceGC
> 
> I don't think `@build` is doing anything here

I would prefer to keep the `@build` tag. Most tests that use `ForceGC` include that `@build` tag, and the [jtreg Tag Spec](https://openjdk.org/jtreg/tag-spec.html) for _ at library_ includes the following:

> In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes. A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled. It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile, and may lead to incomplete recompilation when a test or library code has been modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24143#discussion_r2008124820