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

[Zoltan Herczeg]

Hi Josh,

When a C/C++ function allocates stack space (with decreasing the stack
pointer), it does not initialize the variables there. You need to
initialize them by assignment operators. Reading such variables by the GC
yields an error in valgrind.

Cheers,
Zoltan

> 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
>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>