WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 83839
GC in the middle of JSObject::allocatePropertyStorage can cause badness
https://bugs.webkit.org/show_bug.cgi?id=83839
Summary
GC in the middle of JSObject::allocatePropertyStorage can cause badness
Mark Hahnenberg
Reported
2012-04-12 18:08:25 PDT
Currently, when we're in the middle of JSObject::allocatePropertyStorage, our Structure has inconsistent information. The Structure has just had a property added to it and it thinks it is bigger in both size and capacity, but our actual property backing store is still the same size as before. This can lead the garbage collector to do bad things based on this inaccurate information. We should instead check to see if we need to allocate more space first and do so if necessary, and then add the new property to our structure.
Attachments
Patch
(5.82 KB, patch)
2012-04-12 18:13 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(6.82 KB, patch)
2012-04-12 18:54 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(12.85 KB, patch)
2012-04-13 11:02 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(13.37 KB, patch)
2012-04-13 11:32 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(13.82 KB, patch)
2012-04-13 12:04 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Patch
(13.15 KB, patch)
2012-05-16 11:48 PDT
,
Mark Hahnenberg
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Mark Hahnenberg
Comment 1
2012-04-12 18:13:49 PDT
Created
attachment 137007
[details]
Patch
Build Bot
Comment 2
2012-04-12 18:38:47 PDT
Comment on
attachment 137007
[details]
Patch
Attachment 137007
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/12391710
Mark Hahnenberg
Comment 3
2012-04-12 18:54:47 PDT
Created
attachment 137023
[details]
Patch
Geoffrey Garen
Comment 4
2012-04-12 21:52:56 PDT
Comment on
attachment 137023
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=137023&action=review
I think you want an interface like this: // Add property with structure transition newStorage = reallocPropertyStorage(m_propertyStorage.get(), ...); // Returns new storage, does not assign. newStructure = Structure::addPropertyTransition(...); // Returns new structure, does not assign. setPropertyStorage(newStorage, newStructure); // Assigns structure and storage "atomically". // Add property without structure transition newStorage = reallocPropertyStorage(m_propertyStorage.get(), ...); // Returns new storage, does not assign. setPropertyStorage(newStorage, m_structure.get()); // Assigns structure and storage "atomically". Since storage and structure need to be in sync, we should never set one without setting the other.
> Source/JavaScriptCore/runtime/JSObject.h:661 > + if (structure()->shouldResizePropertyStorage())
Let's call this "shouldGrowPropertyStorage". "Resize" is imprecise, because we don't shrink.
> Source/JavaScriptCore/runtime/JSObject.h:662 > + allocatePropertyStorage(globalData, structure()->propertyStorageCapacity(), structure()->suggestedPropertyStorageResizeAmount());
Let's call this "growPropertyStorage" or "reallocPropertyStorage" to help clarify that we're allocating for a second time.
> Source/JavaScriptCore/runtime/JSObject.h:727 > + Structure* structure = Structure::addPropertyTransition(globalData, this->structure(), propertyName, attributes, specificFunction, offset);
This addPropertyTransition will allocate a new structure, which can cause a GC. During that GC, our Structure's information about our backing store will be out of date (specifically, it will underestimate the size / capacity of our backing store). I'm not sure if that will definitely cause a problem, but it seems not so good. We never want our information about our backing store to be out of date.
Mark Hahnenberg
Comment 5
2012-04-13 11:02:41 PDT
Created
attachment 137104
[details]
Patch
Build Bot
Comment 6
2012-04-13 11:24:40 PDT
Comment on
attachment 137104
[details]
Patch
Attachment 137104
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/12400123
Mark Hahnenberg
Comment 7
2012-04-13 11:32:50 PDT
Created
attachment 137112
[details]
Patch
Build Bot
Comment 8
2012-04-13 11:55:57 PDT
Comment on
attachment 137112
[details]
Patch
Attachment 137112
[details]
did not pass win-ews (win): Output:
http://queues.webkit.org/results/12403044
Mark Hahnenberg
Comment 9
2012-04-13 12:04:39 PDT
Created
attachment 137121
[details]
Patch
Geoffrey Garen
Comment 10
2012-04-13 14:47:23 PDT
Comment on
attachment 137121
[details]
Patch r=me Did the test cases I mentioned pan out?
WebKit Review Bot
Comment 11
2012-04-16 08:10:26 PDT
Comment on
attachment 137121
[details]
Patch Clearing flags on attachment: 137121 Committed
r114255
: <
http://trac.webkit.org/changeset/114255
>
WebKit Review Bot
Comment 12
2012-04-16 08:10:31 PDT
All reviewed patches have been landed. Closing bug.
Mark Hahnenberg
Comment 13
2012-04-16 15:27:42 PDT
<
rdar://problem/10884040
>
Gavin Barraclough
Comment 14
2012-05-08 21:45:52 PDT
Reverted in
r116494
, this causes many failures if COLLECT_ON_EVERY_ALLOCATION is enabled.
Mark Hahnenberg
Comment 15
2012-05-09 15:56:30 PDT
Rolling this change back in since the underlying bug that it revealed should have been fixed in
http://trac.webkit.org/changeset/116565
.
Mark Hahnenberg
Comment 16
2012-05-16 11:48:19 PDT
Created
attachment 142313
[details]
Patch
Mark Hahnenberg
Comment 17
2012-05-16 11:48:42 PDT
Resubmitting patch to make sure everything still builds.
Mark Hahnenberg
Comment 18
2012-05-16 14:20:55 PDT
Committed
r117343
: <
http://trac.webkit.org/changeset/117343
>
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