Disallow soft references in MemoryAssert-related tests in FlowExecutionListTest

[dwnusbaum]

While looking for places to test jenkinsci/jenkins-test-harness#1029, I noticed that this class was allowing soft references while using MemoryAssert.assertGC, so I tracked them down and cleaned them out so the test can run with soft references disallowed.

Testing done

See updated tests.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[dwnusbaum]

It's a bit interesting that I keep running into these cases where first-time initialization of various objects happening in the context of a Pipeline build causes problems. In practice it's probably ok, and at worst they would only cause 1-build leaks, but I wonder how many such leaks are actually possible.

Compare jenkinsci/pipeline-groovy-lib-plugin#199 (comment).

[jglick]

There is a class loader sanity executor service wrapper in Jenkins core which should probably be used.

[dwnusbaum]

Maybe, but this is the common pool, which seems to be unconfigurable, and the reference path was not via Thread.contextClassLoader as is typical (AppClassLoader in this case), but Thread.inheritedAccessControlContext, which holds a reference to CpsGroovyShell$CleanGroovyClassLoader via a ProtectionDomain.classloader, constructed I think via AccessController.getContext().

So whatever the exact problem is, it will go away once we pick up JEP 486 (Java 24+), which deletes Thread.inheritedAccessControlContext.

FWIW also I think the critical usage path of the common pool is via the default executor in Caffeine caches, specifically two caches in SimpleXStreamFlowNodeStorage and one in EnumeratingWhitelist. We could perhaps set their executors to Computer.threadPoolForRemoting or some manually-constructed thread pool to avoid the issue in the meantime.

[jglick]

Ah yes, we ought to define a specific pool for use from Caffeine if possible. Ultimately using virtual threads (21+), though we might need to wait for monitor support in 24, and some diagnosability issues remain.

[dwnusbaum]

The notable thing in these cases is that we are not obviously using any async-related methods or types with the Caffeine caches. We only use weakKeys, strongValues, and LoadingCache, so the fact that an async task is being submitted to the common pool is not immediately obvious. Perhaps it has to do with the internal maintenance referred to in the Javadoc.