Anyone have thoughts on this? I'm happy to go straight to filing a JIRA issue, and can probably PR a fix for this bug as I understand it, but I don't want to plow ahead here if there's a lack of acceptance/belief that this is a real issue - and certainly not if I don't have buy-in on the fix I might write.
Thanks, Chris On Mon, 2 Feb 2026 at 11:50, Chris Dennis <[email protected]> wrote: > Hi All, > > I've been dealing with sporadic failures of Groovy based tests with > false overload disambiguation issues when running on OpenJ9 with > `-Xsoftrefthreshold0` - this essentially turns soft references into weak > references - they get cleared very quickly. The cause for my failures > appears to be that Groovy is relying on referential equality (or > inequality) between CachedClass instances to infer things about the > associated Java class relationship. My logging though shows that the > mapping here isn't truly canonical though - at least not under OpenJ9 in > this configuration. I'm seeing instances where the runtime is comparing two > different instances of CachedClass derived from the same ClassInfo and > falsely inferring that the two classes are distinct and therefore > populating method caches with duplicate method instances and giving me > false ambiguous overload failures. > > I'm attempting to narrow down how exactly this is happening and whether > the cause is OpenJ9 incorrectly clearing a soft reference to a strongly > reachable instance, or is due to Groovy missing one or more > reachabilityFences to prevent early clearing of these references. > > Looking forward to peoples insights and/or thoughts on how best to > approach this. A simple fix would be to only rely on referential > (in)equality for a fast path check, with fallback to a more robust check. > Alternatively, the (much harder) but likely cleaner path is to fix the > underlying Groovy and/or OpenJ9 bug. Note that if this is a Groovy bug > around reachability then I don't think it's safe to assume that this cannot > happen on Hotspot either now, or in the future if/when GC behavior there > changes > > Thanks, > > Chris > > > > >
