Thanks for the reply. I have three more questions regarding this. 1. I'm getting many valgrind memcheck errors. I've added a few suppressions for them but I'm still getting tons of errors. Is this normal? 2. In my debugging, I found that Heap::markConservatively() and other functions are reading from the stack. Heap::markConservatively(), in particular, is scanning for pointers to mark. However some of the stack addresses being read from are reported by valgrind as uninitialized, and I think probably come from stack frame padding. Is this expected? 3. I am seeing some leaks for certain Node objects like FunctionDeclNode. These use reference counting, not GC, but I think some GC'ed JS objects hold on a reference to them. Is there a way to make the collector completely GC everything, so that whatever remains, I can know for sure are true leaks?
Josh On Thu, Sep 11, 2008 at 1:33 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Sep 11, 2008, at 12:13 AM, Josh Chia (谢任中) wrote: > > I did some more research. It seems that KJS does mark-and-sweep > GC<http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html>, > 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. Please correct me if > I'm wrong. > > > More specifically, it marks objects that are reachable from the root set. > > > > On Wed, Sep 10, 2008 at 9:23 PM, Josh Chia (谢任中) <[EMAIL PROTECTED]>wrote: > >> Hi, >> >> I'm trying to debug some memory leaks and now need to understand what >> collector.{h,cpp} are doing. Could someone point me to some documents to >> explain how the garbage collector works? I've also run valgrind and it >> complained that CollectorBitmap::get() uses an unreferenced value. 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. >> > > We don't have detailed docs, but I can give you this overview: > > 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. > > 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. > > 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. > > Regards, > Maciej > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
