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
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 squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
Hm, seems JSC_ZOMBIES do something similar (does it?), I give it a try. Zoltan
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 squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
Yeah, zombies tries to do that, however it tends to be broken after large refactorings because they're not on by default (for obvious reasons). Anything you do to make finding and debuggng gc bugs easier will be welcome :D --Oliver On May 19, 2011, at 1:00 AM, Zoltan Herczeg wrote:
Hm, seems JSC_ZOMBIES do something similar (does it?), I give it a try.
Zoltan
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 squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
participants (2)
-
Oliver Hunt
-
Zoltan Herczeg