This issue may be the same one: https://github.com/apache/royale-compiler/issues/182
I also encountered and fixed an issue related weak references a little over a year ago. Function bodies were getting garbage collected, and I needed to clear out some stale definitions that were causing missing classes in generated ASDoc output and some similar issues with the -watch compiler option. https://github.com/apache/royale-compiler/commit/35eed62f13519c659e6346d26cca3f44afe3170f This fix does not appear to have made it into a release yet. You're not using an older compiler build, right? You've tested that this issue still reproduces using a compiler built from the latest source code? -- Josh Tynjala Bowler Hat LLC https://bowlerhat.dev/ On Sun, May 3, 2026 at 9:40 PM Greg Dove <[email protected]> wrote: > Compiler issues - (Josh, please?) > > We have a medium-sized project that has begun encountering occasional/rare > (but at least daily during normal workloads) compilation issues that appear > to be related to name/type resolution. There can be code within a method > output where the name resolves correctly to its type in one part of the > method's js output and elsewhere within the same js method output as if it > was Object/untyped. This is most obvious with XML or XMLList instances > (because of .child('prop') vs ['prop] differences). I've also seen it get > confused between local variables and instance properties in some cases, > which I believe is a manifestation of the same thing. In other words, > different compilation runs with the exact same settings are not > completely deterministic, because sometimes they can provide different > output. It is very difficult to repro, because it feels so random. But it > has been something that appears to be more frequent as the codebase grows > (when all other settings remain the same). This led me to consider that it > could be GC-related, and I recently removed the SoftReferences inside > ASScopeCache, as a prime suspect. > > After doing this, I have not seen the problem since (so far - after 1.5 > days) > > The ASScopeCache instances themselves are weakly held (inside > CompilerProject). So the internal maps inside each of these instances being > weakly held as well seems to be the problem, the internal maps can perhaps > get into a partially cleared state between threads. > > I did some memory profiling with and without this change for removing the > SoftReferences inside ASScopeCache - but it was quite limited (just testing > with compiling the one project). The memory usage was not much different on > a typical run (approx 1Mb difference for a compilation with around 1000 .as > and .mxml files combined, alongside a bunch of local swcs). There was > possibly a small speed up without the SoftReferences, but I did not test > enough to be sure. > But so far it seems there is not a big impact on memory with omitting > these. If it introduces consistency I'm kinda keen to get it in there - I > know others have definitely seen this problem too. > And for Josh in particular: I think your compiler experience dwarfs the > rest of us and wanted to get your feedback instead of just jumping in with > this one. One option could also be to make this change as a compiler > option, with the new non-weak references being the default, but with the > ability to switch to the older behaviour via the option if that was > considered important as well... look forward to hearing your thoughts. >
