Re: CachedClass referential comparison issues (potential bug)
Jochen Theodorou <[email protected]>
| Newsgroups | gmane.comp.lang.groovy.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2/9/26 22:33, Chris Dennis wrote: > On Mon, 9 Feb 2026 at 15:04, Jochen Theodorou <[email protected]> wrote: >> >> On 02.02.26 17:50, Chris Dennis wrote: [...] > The lazy mechanism is working correctly - the problem is that the > lazily created instances are only softly-referenced which means the GC > can come along later and clean that reference, and then a newly > arriving thread will create an additional instance of CachedClass for > the same type. If/when those two instances then meet they will falsely > compare not-equal and the Groovy runtime will think they represent > different types (which they don't). Maybe what happens is that the class is ready to be collected, but then we use ClassInfo to get the instance, while at the same time we are creating a new instance? Just trying to figure out why two instances even exist. > I think the fix here is to > implement (and use) an equals method for CachedClass which uses this > referential comparison but only as an optimistic fast path. that is a workaround for me though... well... it depends on the conditions we want those constructs to fullfill > (There is > another theoretical fix here where all accesses of a given CachedClass > are always mediated through a single SoftReference, which I think > would make the existing scheme safe, but I fear it would be overly > brittle). This sounds a lot like the soft reference will reference an instance, that only this soft reference will reference. Which would be bad >>> 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? > > I've not been able to reproduce this on anything other than OpenJ9 - > which I suspect is due to OpenJ9 being much more eager to clear > references. I'm pretty sure I have a valid mechanism through which it > can happen though - it just seems to be impossible to make Hotspot > trigger it (so far). Haven't worked with the eclipse/IBM JVm for many years (since Java 9 or so), but I do remember having regularily trouble with the references stuff on there. bye Jochen