> You've tested that this issue still > reproduces using a compiler built from the latest source code?
This was reproduced by a number of devs all working on the same project. And yes, it was with recent builds. I don’t think I personally have seen it (I have a lot of memory on my machine), but it seems to have gotten worse recently. I don’t know if something changed in the compiler or it’s due to the increased project size. This was with variables — not functions. Harbs > On May 4, 2026, at 6:54 PM, Josh Tynjala <[email protected]> wrote: > > 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. >>
