Is it possible for a "false positive" on the stack to prevent an object from being collected even after calling collect() multiple times?
On Thu, Sep 11, 2008 at 9:45 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Sep 11, 2008, at 1:53 AM, Josh Chia (谢任中) wrote: > > 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? > > > 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. > > 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? > > > It is expected and not harmful. A false positive on the conservative scan > is not especially harmful. > > 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? > > > 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. > > - Maciej > > > 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
