WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
148495
DOM Structure and Constructor caches should be weak
https://bugs.webkit.org/show_bug.cgi?id=148495
Summary
DOM Structure and Constructor caches should be weak
Andreas Kling
Reported
2015-08-26 16:32:53 PDT
I don't see why JSDOMGlobalObject's structures() and constructors() caches couldn't be WeakGCMaps instead of strongly owning HashMaps. This would allow us to clean up things that are only used once, e.g by generic feature detection scripts.
Attachments
Patch
(4.94 KB, patch)
2015-08-26 16:36 PDT
,
Andreas Kling
no flags
Details
Formatted Diff
Diff
Patch
(7.17 KB, patch)
2015-08-26 16:36 PDT
,
Andreas Kling
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews104 for mac-mavericks-wk2
(702.31 KB, application/zip)
2015-08-26 17:10 PDT
,
Build Bot
no flags
Details
Archive of layout-test-results from ews103 for mac-mavericks
(577.48 KB, application/zip)
2015-08-26 17:15 PDT
,
Build Bot
no flags
Details
Patch #1: Make DOM Structure and prototype caches weak
(76.78 KB, patch)
2015-10-15 20:37 PDT
,
Andreas Kling
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Andreas Kling
Comment 1
2015-08-26 16:36:06 PDT
Created
attachment 259990
[details]
Patch Let's see what EWS thinks..
Andreas Kling
Comment 2
2015-08-26 16:36:49 PDT
Created
attachment 259991
[details]
Patch Let's see what EWS thinks (about a patch for *this* bug...)
Build Bot
Comment 3
2015-08-26 17:10:11 PDT
Comment on
attachment 259991
[details]
Patch
Attachment 259991
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
http://webkit-queues.webkit.org/results/110859
New failing tests: fast/workers/constructor-proto.html fast/dom/gc-12.html fast/dom/constructors-cached-navigate.html
Build Bot
Comment 4
2015-08-26 17:10:14 PDT
Created
attachment 259999
[details]
Archive of layout-test-results from ews104 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Build Bot
Comment 5
2015-08-26 17:15:32 PDT
Comment on
attachment 259991
[details]
Patch
Attachment 259991
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.webkit.org/results/110881
New failing tests: fast/workers/constructor-proto.html fast/dom/gc-12.html fast/dom/constructors-cached-navigate.html
Build Bot
Comment 6
2015-08-26 17:15:35 PDT
Created
attachment 260000
[details]
Archive of layout-test-results from ews103 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-mavericks Platform: Mac OS X 10.9.5
Andreas Kling
Comment 7
2015-08-27 09:29:32 PDT
Looks like there are two problems here: - DOM Prototypes need to survive if they have custom properties, since losing those after a GC would be observable. - Weak constructors seem to break instanceof somehow. I think it may have something to do with DOM constructor objects only setting the butterfly's "prototype" entry to the DOM prototype, but leaving ObjectPrototype in the Structure::storedPrototype() slot. Something's weird about this.
Andreas Kling
Comment 8
2015-10-15 20:07:36 PDT
(In reply to
comment #7
)
> Looks like there are two problems here: > > - DOM Prototypes need to survive if they have custom properties, since > losing those after a GC would be observable. > > - Weak constructors seem to break instanceof somehow. I think it may have > something to do with DOM constructor objects only setting the butterfly's > "prototype" entry to the DOM prototype, but leaving ObjectPrototype in the > Structure::storedPrototype() slot. Something's weird about this.
lol all wrong The real problem here was that DOM prototypes were retrieved through the DOM Structure cache, and when that was made weak, a GC could destroy e.g the Node Structure, making it impossible for the next caller who wanted the Node prototype to find the NodePrototype we had already instantiated. Gonna break this into two patches so you can see what's going on better.
Andreas Kling
Comment 9
2015-10-15 20:37:18 PDT
Created
attachment 263242
[details]
Patch #1: Make DOM Structure and prototype caches weak
Darin Adler
Comment 10
2015-10-18 16:16:38 PDT
Comment on
attachment 263242
[details]
Patch #1: Make DOM Structure and prototype caches weak Windows build failure is: C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\DerivedSources\ForwardingHeaders\wtf/PassRefPtr.h(42): error C2027: use of undefined type 'WebCore::DOMWrapperWorld' (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCore.vcxproj] C:\cygwin\home\buildbot\WebKit\Source\WebCore\bindings\js\JSDOMGlobalObject.h(37): note: see declaration of 'WebCore::DOMWrapperWorld' (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\DerivedSources\ForwardingHeaders\wtf/RefPtr.h(59): note: see reference to function template instantiation 'void WTF::derefIfNotNull<T>(T *)' being compiled with [ T=WebCore::DOMWrapperWorld ] (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\DerivedSources\ForwardingHeaders\wtf/RefPtr.h(59): note: while compiling class template member function 'WTF::RefPtr<WebCore::DOMWrapperWorld>::~RefPtr(void)' (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) C:\cygwin\home\buildbot\WebKit\Source\WebCore\bindings\js\JSDOMGlobalObject.h(91): note: see reference to function template instantiation 'WTF::RefPtr<WebCore::DOMWrapperWorld>::~RefPtr(void)' being compiled (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) C:\cygwin\home\buildbot\WebKit\Source\WebCore\bindings\js\JSDOMGlobalObject.h(89): note: see reference to class template instantiation 'WTF::RefPtr<WebCore::DOMWrapperWorld>' being compiled (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\DerivedSources\ForwardingHeaders\wtf/PassRefPtr.h(42): error C2227: left of '->deref' must point to class/struct/union/generic type (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCore.vcxproj] C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\DerivedSources\ForwardingHeaders\wtf/PassRefPtr.h(41): warning C4390: ';': empty controlled statement found; is this the intent? (compiling source file C:\cygwin\home\buildbot\WebKit\Source\WebCore\bridge\runtime_root.cpp) [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCore.vcxproj]
Geoffrey Garen
Comment 11
2015-10-19 09:14:07 PDT
> > - DOM Prototypes need to survive if they have custom properties, since > > losing those after a GC would be observable. > > > lol all wrong
But what is the answer to the problem of custom properties on prototypes disappearing?
Andreas Kling
Comment 12
2015-10-19 09:24:29 PDT
(In reply to
comment #11
)
> > > - DOM Prototypes need to survive if they have custom properties, since > > > losing those after a GC would be observable. > > > > > lol all wrong > > But what is the answer to the problem of custom properties on prototypes > disappearing?
... lol even more wrong :|
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