RFR: 8372652: Re-enable LocalRandom clinit after monitor pinning improvements

[Vishal Chand]

On Thu, 27 Nov 2025 23:33:56 GMT, Vishal Chand <duke at openjdk.org> wrote:

> This PR re-enables LocalRandom clinit after monitor pinning improvements.
> Enabling this one would start printing random seeds, which is useful for test debugging.

Hi Everyone,

Apologies for the delay - I just got bandwidth to work on this. I conducted extensive testing to ensure this change is safe and doesn't cause regressions. I stabilized the jtreg results with both the `baseline` and `the change` by running `make test TEST=vmTestbase/ JTREG=TEST_THREAD_FACTORY=Virtual` 3 times for each case to identify `passed`, `flaky`, `failed`, and `errored` tests. Then I ran the `failed` and `errored` tests 10 times each to eliminate flaky tests and get concrete numbers. Below are the results:

**=== BASELINE ===**
Passing (includes Flaky): 3048
Failing + Error: 15

**=== With Change ===**
Passing (includes Flaky): 3048
Failing + Error: 15

The failing tests are **identical** in both cases:

  test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryUsage/from/from001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/from_c/from_c001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/getLockName/getlockname001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/getLockOwnerName/getlockownername001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isInNative/isinnative001/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_directly/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_proxy_custom/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_proxy_default/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_server_custom/TestDescription.java
  test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/baseBehaviorTest_server_default/TestDescription.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jdi/breakpoint/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jdi/breakpointOtherStratum/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/jdi/breakpointInCompiledCode/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/func/jdi/breakpoint/Test.java
  test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/func/jdi/breakpointOtherStratum/Test.java


I verified that the failure reasons are **identical** between baseline and change scenarios.

Based on these results, the change doesn't cause any regressions and is safe to merge.

Please let me know if you need more info, I'll be happy to share.

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

PR Comment: https://git.openjdk.org/jdk/pull/28547#issuecomment-3675825598