Bug 126552 - Marking should be generational
Summary: Marking should be generational
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Hahnenberg
Depends on: 126704
Blocks: 121074
  Show dependency treegraph
Reported: 2014-01-06 17:05 PST by Mark Hahnenberg
Modified: 2014-01-13 08:09 PST (History)
6 users (show)

See Also:

Patch (53.44 KB, patch)
2014-01-07 16:49 PST, Mark Hahnenberg
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hahnenberg 2014-01-06 17:05:07 PST
Re-marking the same objects over and over is a waste of effort. We should use the stick mark bit algorithm along with our already-present write barriers to reduce overhead during garbage collection caused by rescanning objects.
Comment 1 Mark Hahnenberg 2014-01-07 16:49:10 PST
Created attachment 220569 [details]
Comment 2 Geoffrey Garen 2014-01-07 17:34:33 PST
Comment on attachment 220569 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=220569&action=review


> Source/JavaScriptCore/heap/MarkedBlock.h:76
> -        static const size_t atomSize = 8; // bytes
> +        static const size_t atomSize = 16; // bytes

Why 16 byte atoms? Won't this mean that 24 byte objects grow to be 32 bytes? Seems like a memory use regression.
Comment 3 Mark Hahnenberg 2014-01-08 19:45:52 PST
Committed r161540: <http://trac.webkit.org/changeset/161540>
Comment 4 Alexey Proskuryakov 2014-01-09 09:10:48 PST
This change caused assertion failures on multiple tests, most commonly these:


See <http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r161553%20(15185)/results.html> for the crash logs.

Rolling out.
Comment 5 WebKit Commit Bot 2014-01-09 09:12:27 PST
Re-opened since this is blocked by bug 126704
Comment 6 Mark Hahnenberg 2014-01-09 18:25:42 PST
Committed r161615: <http://trac.webkit.org/changeset/161615>
Comment 8 Antti Koivisto 2014-01-13 07:51:28 PST
Filed https://bugs.webkit.org/show_bug.cgi?id=126902 for that
Comment 9 Mark Hahnenberg 2014-01-13 07:51:56 PST
(In reply to comment #7)
> This seems to have significantly (>10%) regressed number of Dromaeo tests:
> https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22mac-mavericks%22%2C%22Dromaeo%2Fdromaeo-core-eval%3ARuns%22%5D%2C%5B%22mac-mavericks%22%2C%22Dromaeo%2Fjslib-attr-prototype%3ARuns%22%5D%2C%5B%22mac-mavericks%22%2C%22Dromaeo%2Fjslib-event-prototype%3ARuns%22%5D%5D&days=17
> Note how rollout fixes the regression and the relanding brings it back.

Theoretically this patch should have been performance neutral (which it was as far as I measured). When enabled I've measured generational collection as ~8% progression on dromaeo. This regression is probably due to some overhead that we're incurring despite GGC being disabled. I can see a few options:

(1) Ignore this because as soon as we turn GGC on in ToT this regression will disappear. 
(2) I can try to fix the regression in ToT by disabling more things that were landed as part of this patch. This might be valuable since we may want to keep the ability to disable/enable GGC as a method for debugging, at least in the near future.
(3) Roll it out again. This is my least favorite option since it mostly just creates more work for me :-/

I'm going to start doing (2). As part of this, I've filed bug 126901.
Comment 10 Ryosuke Niwa 2014-01-13 08:09:30 PST
Sounds like (2) will be a good balance between the two.