Garbage collector issur #4022

[pierrehuber-rd]

Hello, I have posted a new comment in this issue #4022
No response about my comment so I start a new discussion about this.

1. Do you intend to fix this GC regression, and if so, is there a target release?
2. If a fix is not planned in the short term, are you advising that applications should stop using List/DataGrid with complex item renderers (filters, nested groups) on 51.2+, or is there a supported workaround (e.g. a gcEfficiency setting, a rendering-mode change, or a GC-policy tweak) that restores the 51.1.x behaviour?

Thank you

[ajwfrost]

Hi
Sorry, we'd missed the extra comment added to that original issue. Judging by the description of the test case/scenario, this is something we may now be able to reproduce and then fix.
There is a possibility that this may be different from the #4022 one but it's an issue in the same area and introduced around the same time, so hopefully the same.

From the description:

This matches the symptoms already reported in issue #4022 ("shared commit memory rises constantly, especially when you scroll a list with a complex renderer").

Presumably the above was AI-generated, because that title is not the title of 4022, and the symptoms here (increasing memory) are different from 4022 (high CPU usage and app freezing).

But we can take a look...

[pierrehuber-rd]

Hello Andrew,

Thank you for taking this issue into consideration. And yes, AI helped me write a clear description and build a small Flex app to reproduce it.
I don't think this is a separate issue. Even if the app doesn't run out of memory or crash Windows immediately, it would likely show the same behavior after hours of execution. If you can stop the memory growth, that should be enough to prevent the crash.

[ajwfrost]

Hi

Interesting ... so, we can reproduce this in terms of the privateMemory value going up in 51.3.3.2 vs staying flat (with bumps) in 51.1.4.1. And the memory usage in 51.3 is much higher too for some reason!

I think we should be able to try tracking down the commit that caused the problem, although it may be a bit of a painstaking process. But thank you for the test case and details!

thanks

[ajwfrost]

Some interesting findings here .. is that it might be more related to the ADL binary than the runtime DLL. Which is odd.

We also went back to check the latest builds: with 51.3.3.2, the "going up" was after we left the test running for ages. And depending on the test, you might expect that to happen just due to fragmentation and the standard AVM+ memory model. But with earlier versions (51.2) we could see a much more obvious/massive increase in memory a lot more quickly, to the extent that it maximised out the physical memory usage and once caused a PC crash.

Could you see if you get the same results e.g. if you think it's working okay with 51.1.4, then use something like:

air_51.1.4\bin\adl64.exe -runtime air_51.2.1\runtimes\air\win64 MemTest-app.xml

Looking at the ADL history, in May 2024 (in 51.0.1.2) we added the "large address aware" flag for Windows 32-bit builds, but I can't see what might have changed the memory behaviour like this..!

Needs a bit more investigation I think..