The first thing that comes to mind off-hand is https://git.gnome.org/browse/gjs/commit/?id=bcb5924661587, which turned out to introduce some serious leaks late in the cycle :-(

In particular https://git.gnome.org/browse/gjs/commit/?id=9050118c9e7 showed up prominently in valgrind logs and was only identified/fixed during hard code freeze - can you make sure that the upgrade already brought in gjs 1.48.0?

Otherwise a valgrind log would help.

I've got gjs 1.48.0. This is output of valgrind --tool=memcheck polari:
https://paste.gnome.org/p8unfygtc

Mmh, that doesn't look useful - no leak information, and polari crashed :-(

Yeah, Polari actually didn't fully run in the valgrind test, it started, drew the screen with rooms and that was it. Whenever I tried to do something, I got the "unresponsive app" dialog. I don't know why, maybe it ran out of memory. But it's probably the reason why the log is not useful.

Created attachment 349173 [details]
Output of valgrind massif

I'm adding an output from a valgrind-massif. Hopefully it's more useful. Just at the first glance I see hunspell eating 500 MB of memory. That doesn't seem right.

Created attachment 349180 [details] [review]
entryArea: Share a common spell checker

We currently use GSpell's convenience API to add spell checking
support to entries, which turns out to be quite wasteful when
used with lots of separate entries:
Every entry gets a separate GSpellChecker object with its own copy
of the dictionary.
Address this by setting up all entries manually with a shared spell
checker object.

Attachment 349180 [details] pushed as d9e975f - entryArea: Share a common spell checker

Sorry, I didn't mean to close this until we can confirm that loading the spell checking dictionaries more than once was indeed the issue you were seeing.

The leak seems to be fixed in 3.24.1. Now Polari takes 160 MB of memory which is in line with other applications.

OK, thanks for the confirmation.