Bug 110519 - Object allocation profiling will refuse to create objects with more than JSFinalObject::maxInlineCapacity() inline slots, but JSFunction::allocationProfile() asserts that the number of inline slots is always what it asked for
Summary: Object allocation profiling will refuse to create objects with more than JSFi...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-21 15:09 PST by Filip Pizlo
Modified: 2013-02-21 16:57 PST (History)
7 users (show)

See Also:

Attachments
tbhe patch (1.42 KB, patch)
2013-02-21 15:10 PST, Filip Pizlo 		ggaren: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2013-02-21 15:09:44 PST 
Basically, JSFunction is asserting that the object allocation profiling doesn't have the max-out feature.  But it does have that feature, for good reason.
Comment 1 Filip Pizlo 2013-02-21 15:10:55 PST 
Created attachment 189608 [details]
tbhe patch
Comment 2 Geoffrey Garen 2013-02-21 15:13:12 PST 
Comment on attachment 189608 [details]
tbhe patch

r=me

Would be nice to rename the argument to inferredInlineCapacity, too. The convention is that "inlineCapacity" means the real number, and not the guess.
Comment 3 Filip Pizlo 2013-02-21 15:43:36 PST 
(In reply to comment #2)
> (From update of attachment 189608 [details])
> r=me
> 
> Would be nice to rename the argument to inferredInlineCapacity, too. The convention is that "inlineCapacity" means the real number, and not the guess.

I'll leave that for later.

Also, there's no good test for this.  The key thing is that the JSFunction must survive but the CodeBlock must be blown away.  Otherwise we never take that path in JSFunction::allocationProfile().
Comment 4 Filip Pizlo 2013-02-21 16:57:48 PST 
Landed in http://trac.webkit.org/changeset/143667