GNOME 3.28.2 Released With GJS Garbage Collection Fix To Address The Big Memory Leak

[justmy2cents]

Yes. the description is not correct. Rea.d

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

"The garbage collector is scheduled every time a GObject wrapped in GJS has its toggle reference gone from >1 to 1. And scheduled here means that a GC is injected into the mainloop as an idle callback, that will be executed when there’s nothing else to be executed in the mainloop. The absolute majority of the time, it means that only one GC will happen, even if hundreds of GObjects are disposed."

thanks for clarification and link. that makes much more sense

[RahulSundaram]

if it really works like that, then this one terrible, terrible fix. more like trading one problem for another one with different effects while being just as bad as the original one. one would really hope there is some mistake in your interpretation of the fix

Yes. the description is not correct. Read

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

"The garbage collector is scheduled every time a GObject wrapped in GJS has its toggle reference gone from >1 to 1. And scheduled here means that a GC is injected into the mainloop as an idle callback, that will be executed when there’s nothing else to be executed in the mainloop. The absolute majority of the time, it means that only one GC will happen, even if hundreds of GObjects are disposed."

[justmy2cents]

The "fix" just triggers the GC every time an object is flagged for destruction. This trades increased CPU overhead for a more consistent and reduced memory usage.

if it really works like that, then this one terrible, terrible fix. more like trading one problem for another one with different effects while being just as bad as the original one. one would really hope there is some mistake in your interpretation of the fix

if garbage collection is triggered when you mass remove memory segments for each segment? that results in insane amounts of extra executions where main point of gc is to remove that from happening as much and cleaning up in chunks when there is available cpu time

now, if the solution at least has some sort of additive timer where it simply caches deletes and waits for certain interval (or delete quantity) to pass and then triggers that in lazy mode. that is something completely different as it will still act as gc, but in controlled manner

[newwen]

Calling this a memory leak is a big misrepresentation. It is not a leak, but an undetermined delay (yet not infinite) in memory deallocation of reference counted objects. Memory is never lost, whereas in a real memory leak it would. The "fix" just triggers the GC every time an object is flagged for destruction. This trades increased CPU overhead for a more consistent and reduced memory usage.

[MihaiBojescu]

Does this address (at least a part of) the performance issues Gnome is having?

[uid313]

I would like to see gnome-extension-tool generate JavaScript ES6 classes.

[froyo]

Is anybody aware of a bug report for Fedora 28? I would like to follow this bug but cannot find it. I that this is due to me, and not due to nobody having reported it yet.

[Sethox]

It's good that they fixed it, the consequence of this is that the people is going to wonder "why did it take so long?".

[RahulSundaram]

Semantics doesn't change the fact it would eat many gigabytes of ram in a short period of time and slowed systems to a crawl.

Most real memory leaks found in code aren't even nearly that bad, and this one went on for quite a while before it got enough media attention that they finally bothered to fix it.

Media attention wasn't the factor here.

It was just a series of actual memory leak fixes that they did over a period of time for problems that affected some systems and the recent fix which wasn't a memory leak but more aggressive garbage collection was for something they have had trouble tracking down the cause for and resolve in a reasonable way.

[calc]

It was not a memory leak.

Semantics doesn't change the fact it would eat many gigabytes of ram in a short period of time and slowed systems to a crawl.

Most real memory leaks found in code aren't even nearly that bad, and this one went on for quite a while before it got enough media attention that they finally bothered to fix it.