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

[Josh Chia (谢任中)]

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 <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/f28f6788/attachment.html