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

[phoronix]

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

The second and final planned point/bug-fix release to GNOME 3.28 is now available...

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-3.28.2-Released

[tessio]

It was not a memory leak.

[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.

[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.

[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?".

[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.

[uid313]

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

[MihaiBojescu]

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

[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.

[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