Summary: | REGRESSION(r92092): Build fails on 64 bit | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> | ||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Blocker | CC: | fpizlo, ggaren, oliver, webkit.review.bot, zherczeg | ||||||
Priority: | P1 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 65437, 65840 | ||||||||
Attachments: |
|
Description
Csaba Osztrogonác
2011-08-01 02:49:27 PDT
Created attachment 102514 [details]
preliminary patch
This patch fixes the compile assert but it cause an infinite loop as it creates a block with cellSize 0. There is some hidden dependency between the blocks and values.
Geoff, any idea?
(In reply to comment #1) > Created an attachment (id=102514) [details] > preliminary patch > > This patch fixes the compile assert but it cause an infinite loop as it creates a block with cellSize 0. There is some hidden dependency between the blocks and values. > > Geoff, any idea? The issue is with the logic in sizeClassFor(). The preciseCutoff is actually the smallest allocation size for imprecise size classes, rather than the upper bound on sizes for precise size classes. So for example in the current scheme, a 120 byte allocation should be allocated as 128 bytes, and so it should go to an imprecise size class. So the number of size classes is not wrong, but the selection algorithm is. I've got a patch for this and am testing it now... Created attachment 102556 [details]
the patch
I believe that this is the more appropriate fix...
Comment on attachment 102556 [details] the patch Clearing flags on attachment: 102556 Committed r92146: <http://trac.webkit.org/changeset/92146> All reviewed patches have been landed. Closing bug. Hey Filip! Thank you for fixing this. Could you fix both comments as well: // [ 8, 16... 128 ) // [ 128, 256... 1024 ) (RS=me) |