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
