Carlos Garnacho authored Apr 23, 2018 and Philip Chimento committed May 21, 2018

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.

#151

Closes: #151