I've started writing up a page detailing how to avoid screwing up GC, it's far from complete but it has some info that may be useful to people: https://trac.webkit.org/wiki/How%20to%20not%20mess%20up%20GC
In response to the other questions: It is still mark/sweep, Cells are no longer fixed size, it doesn't move anything, Weak<> and Strong<> are handles in the usual gc sense -> they're pointers to pointers (or in this case JSValues) --Oliver On May 18, 2011, at 10:54 AM, Zoltan Herczeg wrote: > Hi, > > I am currently debugging a nasty GC bug. (This one: > https://bugs.webkit.org/show_bug.cgi?id=60881) In short, > inspector/styles/metrics-box-sizing.html fails in the interpreter with > ASSERT_GC_OBJECT_LOOKS_VALID(cell) if all inspector/ tests are running by > run-webkit-tests (32 bit, debug mode), but it passes if you test it alone. > > Actually for tracking memory related issues the valgrind tool has an > excellent approach: never reuse the same address. This way we can keep > track of the freed chunks. Would it be possible to implement something > similar in the GC for JavaScriptCore (disabled by default with some > directives)? We would still run the GC as usual, but instead of reusing > the cells, we would always allocate a new chunk bz mmap. Naturally the > freed cells would contain some invalid pointers to cause crashes, and > perhaps a descriptor which describes where it was originally allocated. > Would it be feasible to add such feature to JavaScriptCore? > > Besides I saw a lot of improvements in GC. Is it still a mark and don't > sweep allocator? Is it still allocates fixed size cells? Does it move > cells? Does Weak<T> contains a GC'ed pointer? > > Regards, > Zoltan > > > _______________________________________________ > squirrelfish-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev _______________________________________________ squirrelfish-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
