# Memprof / GC dynamics

**URL:** <https://www.ruby-forum.com/t/memprof-gc-dynamics/184031>\
**Category:** Ruby\
**Created:** [February 24, 2010, 12:46am UTC](https://www.ruby-forum.com/t/memprof-gc-dynamics/184031 "2010-02-24T00:46:46Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![thegoatboy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/9fc348/32.png) [@thegoatboy](https://www.ruby-forum.com/u/thegoatboy)\
**Post date:** [February 24, 2010, 12:46am UTC](https://www.ruby-forum.com/t/memprof-gc-dynamics/184031/1 "2010-02-24T00:46:46Z")

</div>

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 …`

---

<div class="post-metadata">

**Author:** ![thegoatboy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/9fc348/32.png) [@thegoatboy](https://www.ruby-forum.com/u/thegoatboy)\
**Post date:** [February 24, 2010, 6:44pm UTC](https://www.ruby-forum.com/t/memprof-gc-dynamics/184031/2 "2010-02-24T18:44:46Z")

</div>

> 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