On Fri, 21 Mar 2025 14:24:13 GMT, Mikhail Yankelevich <myankelev...@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 _@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
