-
JS_GC() during gjs regular operation will indeed end up scheduling objects for destruction in a timely manner. However on long lived applications object creation/destruction patterns may leave uneven gaps in JS heap arenas that get harder and harder to reuse. Side effects may include more expensive/infructuous GC-ing and increased memory usage. Introduce the compacting GC [1], a (slightly more expensive) GC mode that is able to transparently compact underused arenas. This mode does not happen by default, Firefox explicitly triggers it from DOM code on user inactivity and memory pressure situations. We can do similarly, one ideal place to call this is gjs_gc_if_needed(), since we are interested on the application giving up as many pages as it can. This keeps memory fragmentation on hold, helping gnome-shell memory usage stay within certain parameters on long running sessions. [1] https://hacks.mozilla.org/2015/07/compacting-garbage-collection-in-spidermonkey/ [skip cpplint] because of having to include jsapi-wrapper before SpiderMonkey headers. GNOME/gjs#151 Closes: #151
be0d5322