<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 11, 2008, at 1:53 AM, Josh Chia (谢任中) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Thanks for the reply. &nbsp;I have three more questions regarding this.<div><br></div><div>1. I'm getting many valgrind memcheck errors. &nbsp;I've added a few suppressions for them but I'm still getting tons of errors. &nbsp;Is this normal?</div></div></blockquote><div><br></div><div>I think valgrind is overzealous here - it can't tell when we are setting only one of a group of bits, and perhaps doesn't detect that our memory is initially zero-fill.</div><br><blockquote type="cite"><div dir="ltr"> <div>2. In my debugging, I found that&nbsp;<span class="Apple-style-span" style="border-collapse: collapse; ">Heap::markConservatively() and other functions are reading from the stack. &nbsp;Heap::markConservatively(), in particular, is scanning for pointers to mark. &nbsp;However some of the stack addresses being read from are reported by valgrind as uninitialized, and I think probably come from stack frame padding. &nbsp;Is this expected?</span></div></div></blockquote><div><br></div><div>It is expected and not harmful. A false positive on the conservative scan is not especially harmful.</div><br><blockquote type="cite"><div dir="ltr"> <div>3. I am seeing some leaks for certain Node objects like FunctionDeclNode. &nbsp;These use reference counting, not GC, but I think some GC'ed JS objects hold on a reference to them. &nbsp;Is there a way to make the collector completely GC everything, so that whatever remains, I can know for sure are true leaks?</div></div></blockquote><div><br></div><div>Function objects hold on to things like FuncDeclNode. You can call collect() manually to force a GC. We have a dialog in the Safari Debug menu that lets you do that.</div><div><br></div><div>&nbsp;- Maciej</div><br><blockquote type="cite"><div dir="ltr"> <div><br></div><div>Josh</div><div><br><div class="gmail_quote">On Thu, Sep 11, 2008 at 1:33 AM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div style="word-wrap:break-word"><br><div><div class="Ih2E3d"><div>On Sep 11, 2008, at 12:13 AM, Josh Chia (谢任中) wrote:</div><br><blockquote type="cite"><div dir="ltr"><a></a>I did some more research. &nbsp;It seems that KJS does <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html" target="_blank">mark-and-sweep GC</a>, and the marking is to mark objects that are not known to be unreachable, so that those left unmarked can be removed at the end. &nbsp;Please correct me if I'm wrong.</div> </blockquote><div><br></div></div><div>More specifically, it marks objects that are reachable from the root set.</div><div class="Ih2E3d"><br><blockquote type="cite"><div dir="ltr"><br> <br><div class="gmail_quote">On Wed, Sep 10, 2008 at 9:23 PM, Josh Chia (谢任中) <span dir="ltr">&lt;<a href="mailto:joshchia@gmail.com" target="_blank">joshchia@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">Hi,<br><br>I'm trying to debug some memory leaks and now need to understand what collector.{h,cpp} are doing.&nbsp; Could someone point me to some documents to explain how the garbage collector works?&nbsp; I've also run valgrind and it complained that CollectorBitmap::get() uses an unreferenced value.&nbsp; I'm not sure whether this is really wrong, so I'll have to first understand how the garbage collector works, the alignment magic used with JSCell and whatever other GC magic I could probably figure out on my own but only after staring at the code for a long time.</div> </blockquote></div></div></blockquote><div><br></div></div><div>We don't have detailed docs, but I can give you this overview:</div><div><br></div><div>The basic algorithm is mark and sweep. It's partially conservative - it does a conservative scan of the stack for references but is exact with respect to the heap (both its own and the C++ heap). Some of the code may confuse valgrind but I do not believe there is actual uninitialized access.</div> <div><br></div><div>We arrange it so collector cells are always allocated at a multiple of a power of two, this helps in part by making the conservative scan cheaper.</div><div><br></div><div>It's really pretty straightforward in terms of algorithms, a fairly amateur (but surprisingly effective) take on a garbage collector. In the future we'd like to consider using a copying collector that supports variable-sized allocations.</div> <div><br></div><div>Regards,</div><div>Maciej</div><font color="#888888"><div><br></div></font></div></div></blockquote></div><br></div></div></blockquote></div><br></body></html>