RESOLVED FIXED 96214
Added large allocation support to MarkedSpace 
https://bugs.webkit.org/show_bug.cgi?id=96214
Summary Added large allocation support to MarkedSpace
Geoffrey Garen
Reported 2012-09-09 12:53:23 PDT
Added large allocation support to MarkedSpace
Attachments
Patch (24.34 KB, patch)
2012-09-09 13:39 PDT, Geoffrey Garen 		no flags
DetailsFormatted DiffDiff
Patch (25.19 KB, patch)
2012-09-09 14:09 PDT, Geoffrey Garen 		no flags
DetailsFormatted DiffDiff
Patch (25.24 KB, patch)
2012-09-09 15:04 PDT, Geoffrey Garen 		no flags
DetailsFormatted DiffDiff
Patch (15.01 KB, patch)
2012-09-10 19:21 PDT, Geoffrey Garen 		buildbot: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
Geoffrey Garen
Comment 1 2012-09-09 13:39:03 PDT
Created attachment 163010 [details] Patch
Filip Pizlo
Comment 2 2012-09-09 13:45:27 PDT
Comment on attachment 163010 [details] Patch I'm not sure I buy the removal of imprecise size classes. That seems like a pure regression. Why aren't you just using the large allocation support for >=64KB allocations?
Build Bot
Comment 3 2012-09-09 14:02:26 PDT
Comment on attachment 163010 [details] Patch Attachment 163010 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/13797564
Geoffrey Garen
Comment 4 2012-09-09 14:09:47 PDT
Created attachment 163011 [details] Patch
Geoffrey Garen
Comment 5 2012-09-09 14:20:11 PDT
> Why aren't you just using the large allocation support for >=64KB allocations? Currently, our fixed allocators only go up to 2KB. So, I had to choose: - add 1024 "imprecise" allocators - increase the "imprecise" allocator slop, and add < 1024 "imprecise" allocators - over-allocate large allocations by up to 62KB - support < 64KB with the large allocator I slightly preferred supporting < 64KB with the large allocator because: - it makes a few large allocations actually happen in TOT, to give the code path some testing - the other options optimize some things while pessimizing others, which feels like an odd thing to do since they literally never happen in TOT
Geoffrey Garen
Comment 6 2012-09-09 14:21:16 PDT
> I'm not sure I buy the removal of imprecise size classes. That seems like a pure regression. Regression measured by what?
Build Bot
Comment 7 2012-09-09 14:42:01 PDT
Comment on attachment 163011 [details] Patch Attachment 163011 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/13798568
Geoffrey Garen
Comment 8 2012-09-09 15:04:54 PDT
Created attachment 163016 [details] Patch
Geoffrey Garen
Comment 9 2012-09-10 19:21:14 PDT
Created attachment 163266 [details] Patch
Geoffrey Garen
Comment 10 2012-09-10 19:24:01 PDT
Large for >= 64KB turned out to be a simpler implementation, so I've restored the imprecise size classes.
Build Bot
Comment 11 2012-09-10 19:57:58 PDT
Comment on attachment 163266 [details] Patch Attachment 163266 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/13827026
Geoffrey Garen
Comment 12 2012-09-10 20:02:13 PDT
Committed r128141: <http://trac.webkit.org/changeset/128141>
Note You need to log in before you can comment on or make changes to this bug.