memprof / GC dynamics

[Steven Parkes]

Wow, memprof is great stuff.

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

I have

<code>
Memprof.start # optionally
GC.start
<code>

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

 

[Roger Pack]

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