WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
125472
ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at beginning of GC
https://bugs.webkit.org/show_bug.cgi?id=125472
Summary
ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at b...
Mark Hahnenberg
Reported
2013-12-09 16:00:10 PST
We already assume that we might do some allocation during DFG plan finalization, so we just need to flip the proper bits so that the ASSERT doesn't fire in this situation.
Attachments
Patch
(9.24 KB, patch)
2013-12-09 16:44 PST
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(11.77 KB, patch)
2013-12-09 18:45 PST
,
Mark Hahnenberg
ggaren
: review+
eflews.bot
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Mark Hahnenberg
Comment 1
2013-12-09 16:44:34 PST
Created
attachment 218812
[details]
Patch
EFL EWS Bot
Comment 2
2013-12-09 16:52:10 PST
Comment on
attachment 218812
[details]
Patch
Attachment 218812
[details]
did not pass efl-ews (efl): Output:
http://webkit-queues.appspot.com/results/47238202
EFL EWS Bot
Comment 3
2013-12-09 16:59:00 PST
Comment on
attachment 218812
[details]
Patch
Attachment 218812
[details]
did not pass efl-wk2-ews (efl-wk2): Output:
http://webkit-queues.appspot.com/results/45888244
Build Bot
Comment 4
2013-12-09 17:16:59 PST
Comment on
attachment 218812
[details]
Patch
Attachment 218812
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
http://webkit-queues.appspot.com/results/47248248
Build Bot
Comment 5
2013-12-09 17:28:02 PST
Comment on
attachment 218812
[details]
Patch
Attachment 218812
[details]
did not pass win-ews (win): Output:
http://webkit-queues.appspot.com/results/47288220
Build Bot
Comment 6
2013-12-09 17:28:24 PST
Comment on
attachment 218812
[details]
Patch
Attachment 218812
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.appspot.com/results/47228237
Mark Hahnenberg
Comment 7
2013-12-09 18:45:22 PST
Created
attachment 218819
[details]
Patch
EFL EWS Bot
Comment 8
2013-12-09 20:45:23 PST
Comment on
attachment 218819
[details]
Patch
Attachment 218819
[details]
did not pass efl-wk2-ews (efl-wk2): Output:
http://webkit-queues.appspot.com/results/46278321
Geoffrey Garen
Comment 9
2013-12-09 21:18:56 PST
Comment on
attachment 218819
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=218819&action=review
r=me
> Source/JavaScriptCore/heap/Heap.cpp:759 > + PretendAllocationOkay pretend(*this);
I don't like the word "pretend" here because it implies that we're only silencing ASSERTs, when in reality we're making material changes that make the difference between allocating being OK or not. How about "RecursiveAllocationScope"?
> Source/JavaScriptCore/heap/Heap.cpp:760 > + m_vm->prepareToDiscardCode();
Do we need to do this in every GC, or only if we're going to discard code? Seems weird, and unnecessarily costly, to do this if we're not going to discard code.
Mark Hahnenberg
Comment 10
2013-12-10 08:25:45 PST
Comment on
attachment 218819
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=218819&action=review
>> Source/JavaScriptCore/heap/Heap.cpp:759 >> + PretendAllocationOkay pretend(*this); > > I don't like the word "pretend" here because it implies that we're only silencing ASSERTs, when in reality we're making material changes that make the difference between allocating being OK or not. How about "RecursiveAllocationScope"?
OK.
>> Source/JavaScriptCore/heap/Heap.cpp:760 >> + m_vm->prepareToDiscardCode(); > > Do we need to do this in every GC, or only if we're going to discard code? Seems weird, and unnecessarily costly, to do this if we're not going to discard code.
I think this is an unfortunately named method. We have an invariant right now that there can be no concurrent compilation going on during garbage collection, which is what "prepareToDiscardCode()" enforces, i.e. it finishes any remaining compilation work which then prevents any further concurrent compilation. I don't think this invariant is only related to discarding code. There are lots of assumptions in how concurrent compilation works that are built on top of the fact that a GC absolutely cannot occur in the middle of a compilation. For example, I believe LUB-ing of value profiles, array profiles, etc. depend on the fact that the object they grab from the profile is not a stale reference to a dead object.
Mark Hahnenberg
Comment 11
2013-12-10 11:34:31 PST
Committed
r160377
: <
http://trac.webkit.org/changeset/160377
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug