RESOLVED FIXED 136055
DFG::freezeFragile should register the frozen value's structure
https://bugs.webkit.org/show_bug.cgi?id=136055
Summary DFG::freezeFragile should register the frozen value's structure
Filip Pizlo
Reported 2014-08-18 17:53:18 PDT
...
Attachments
the patch (4.12 KB, patch)
2015-06-30 16:36 PDT, Filip Pizlo
ggaren: review+
the patch (5.46 KB, patch)
2015-07-01 18:09 PDT, Filip Pizlo
mark.lam: review+
Filip Pizlo
Comment 1 2015-06-30 16:33:13 PDT
I believe that we previously did not do this because of the suspicion that it might be worthwhile to sometimes track a value without tracking its structure. But right now all users of freeze() will eventually register the value's structure, except in cases where they obviously should but they obviously don't. That causes bugs. It would be easier to just make freeze() always register the structure and then not have any doubts about whose responsibility it is.
Filip Pizlo
Comment 2 2015-06-30 16:36:54 PDT
Created attachment 255873 [details] the patch
Geoffrey Garen
Comment 3 2015-07-01 10:51:24 PDT
Comment on attachment 255873 [details] the patch r=me
Mark Lam
Comment 4 2015-07-01 11:11:02 PDT
Comment on attachment 255873 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=255873&action=review > Source/JavaScriptCore/dfg/DFGStructureRegistrationPhase.cpp:55 > for (FrozenValue* value : m_graph.m_frozenValues) > - registerStructure(value->structure()); > + m_graph.assertIsRegistered(value->structure()); According to Graph::freezeFragile() and FrozenValue::freeze(), we can freeze non-cell values. In those cases, value->structure() is a nullptr. Is this assertion valid without a nullcheck on value->structure() first? In Graph::assertIsRegistered(), it looks like it will deref the passed in structure without any checks.
Filip Pizlo
Comment 5 2015-07-01 11:21:40 PDT
(In reply to comment #4) > Comment on attachment 255873 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=255873&action=review > > > Source/JavaScriptCore/dfg/DFGStructureRegistrationPhase.cpp:55 > > for (FrozenValue* value : m_graph.m_frozenValues) > > - registerStructure(value->structure()); > > + m_graph.assertIsRegistered(value->structure()); > > According to Graph::freezeFragile() and FrozenValue::freeze(), we can freeze > non-cell values. In those cases, value->structure() is a nullptr. Is this > assertion valid without a nullcheck on value->structure() first? In > Graph::assertIsRegistered(), it looks like it will deref the passed in > structure without any checks. Wow, good catch! It turns out that this works because assertIsRegistered() returns early before the end of the structure registration phase. So this is just a broken no-op! I'll fix and post a new patch.
Filip Pizlo
Comment 6 2015-07-01 18:08:43 PDT
(In reply to comment #5) > (In reply to comment #4) > > Comment on attachment 255873 [details] > > the patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=255873&action=review > > > > > Source/JavaScriptCore/dfg/DFGStructureRegistrationPhase.cpp:55 > > > for (FrozenValue* value : m_graph.m_frozenValues) > > > - registerStructure(value->structure()); > > > + m_graph.assertIsRegistered(value->structure()); > > > > According to Graph::freezeFragile() and FrozenValue::freeze(), we can freeze > > non-cell values. In those cases, value->structure() is a nullptr. Is this > > assertion valid without a nullcheck on value->structure() first? In > > Graph::assertIsRegistered(), it looks like it will deref the passed in > > structure without any checks. > > Wow, good catch! It turns out that this works because assertIsRegistered() > returns early before the end of the structure registration phase. So this > is just a broken no-op! I'll fix and post a new patch. And this revealed a bug. freezeFragile() was loading the structure and registering it, but then the act of freezing would load the structure a second time. That was racy. The fix is to load the structure only once. Posting new patch now...
Filip Pizlo
Comment 7 2015-07-01 18:09:06 PDT
Created attachment 255979 [details] the patch
Mark Lam
Comment 8 2015-07-01 18:23:42 PDT
Comment on attachment 255979 [details] the patch r=me
Filip Pizlo
Comment 9 2015-07-01 18:31:56 PDT
Note You need to log in before you can comment on or make changes to this bug.