[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