On 02.02.26 17:50, Chris Dennis 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 don't quite understand... the ClassInfo holds the reference to
ChachedClass and creates it lazy... so maybe what happens is that the
lazy mechanism is not 100% right and two CachedClass instances are created?
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.
Can you verify other JVMs as well?
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
ideally we fix the bug in Groovy, if it is in Groovy. I highly doubt all
JVMs have this problem if it is from the JVM
bye Jochen
