[webkit-dev] How does the Javascript garbage collection work?
Maciej Stachowiak
mjs at apple.com
Thu Sep 11 09:45:13 PDT 2008
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 <mjs at apple.com>
> 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, 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 (谢任中) <joshchia at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080911/98e8eccd/attachment.html
More information about the webkit-dev
mailing list