[webkit-dev] How does the Javascript garbage collection work?

[Josh Chia (谢任中)]

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 <mjs at apple.com> 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 <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<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 (谢任中) <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/afac20fd/attachment.html