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 <[EMAIL PROTECTED]>
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 (谢任中) <[EMAIL PROTECTED]> 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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
