Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • justmy2cents
    replied
    Originally posted by RahulSundaram View Post
    Yes. the description is not correct. Rea.d

    https://feaneron.com/2018/04/20/the-...l-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

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by justmy2cents View Post

    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-...l-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."


    Leave a comment:


  • justmy2cents
    replied
    Originally posted by newwen View Post
    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

    Leave a comment:


  • newwen
    replied
    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.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • froyo
    replied
    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.

    Leave a comment:


  • Sethox
    replied
    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?".

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by calc View Post

    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.
    Last edited by RahulSundaram; 10 May 2018, 11:24 PM.

    Leave a comment:


  • calc
    replied
    Originally posted by tessio View Post
    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.

    Leave a comment:

Working...
X