Would you be willing to give me access to the project? If it isn't too difficult to reproduce, I may be able to figure out what's going on and how to restore the missing typing data, similar to my other fix. My feeling is that the original Adobe devs intended for occasional garbage collection to occur to stay within memory limits, but that the data would be restorable, if needed later. I think that they simply missed some places where it might need to be restored because it happens pretty rarely. Or maybe our newer JS emitter isn't properly accounting for that possibility.
-- Josh Tynjala Bowler Hat LLC https://bowlerhat.dev/ On Mon, May 4, 2026 at 10:37 AM Harbs <[email protected]> wrote: > > 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. > >> > >
