Memprof / GC dynamics

Wow, memprof is great stuff.

I have a case I don’t really understand, though. (On 1.8.7-p249)

I have

Memprof.start # optionally GC.start

Whether I have the Memprof.start call in there or not changes the
results of GC.start. [GC.start should be a complete mark/sweep,
shouldn’t it?]

My context is Johnson, which is linking to Spidermonkey, the Mozilla JS
interpreter. Johnson has C ext Ruby objects that are roots to
Spidermonkey’s GC. If I run GC.start w/o Memprof.start, it appears Ruby
refs are getting through the GC and staying roots to Spidermonkey.
Simply adding Memprof.start changes this: the GC.start does (apparently)
free those roots.

I don’t know that this is related to Memprof per-se: just happened to be
what I was using. Is this simply stack shadowing, with Memprof dirtying
the stack enough that Ruby doesn’t see any false references?

I suppose I should try on REE …

Whether I have the Memprof.start call in there or not changes the
results of GC.start. [GC.start should be a complete mark/sweep,
shouldn’t it?]

Maybe it’s retaining references to your existing objects, but also it’s
possible that it’s spawning some other thread and since ruby uses green
threads the other threads can retain “old references” to local stuff,
etc.
REE or 1.9 shouldn’t have the problem I describe above, but it’s still
possible that the stack of the thread has old refs to stuff.
-r