Sure. I’ll be in touch off list.
> On May 4, 2026, at 9:18 PM, Josh Tynjala <[email protected]> wrote:
>
> 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.
>>>>
>>
>>
