RESOLVED FIXED Bug 160497
MemoryPressureHandler shouldn't know how to release WebCore memory
https://bugs.webkit.org/show_bug.cgi?id=160497
Summary MemoryPressureHandler shouldn't know how to release WebCore memory
Carlos Garcia Campos
Reported 2016-08-03 04:53:27 PDT
All processes should set their own low memory handler, instead of leaving the web process using the default one that needs to access APIs that are not in platform layer.
Attachments
WIP patch (35.52 KB, patch)
2016-08-03 05:08 PDT, Carlos Garcia Campos
no flags
Rebased patch (35.50 KB, patch)
2016-09-19 05:57 PDT, Carlos Garcia Campos
no flags
Rebased patch (35.49 KB, patch)
2016-10-14 02:48 PDT, Carlos Garcia Campos
no flags
Patch (41.34 KB, patch)
2016-10-14 03:32 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.51 KB, patch)
2016-10-14 04:06 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.55 KB, patch)
2016-10-14 04:55 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.54 KB, patch)
2016-10-14 05:28 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.57 KB, patch)
2016-10-14 05:48 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.57 KB, patch)
2016-10-14 06:11 PDT, Carlos Garcia Campos
no flags
Try to fix mac build (41.88 KB, patch)
2016-10-14 06:27 PDT, Carlos Garcia Campos
buildbot: commit-queue-
Archive of layout-test-results from ews113 for mac-yosemite (872.87 KB, application/zip)
2016-10-14 07:20 PDT, Build Bot
no flags
Try to fix wk1 crashes (42.00 KB, patch)
2016-10-14 08:42 PDT, Carlos Garcia Campos
no flags
Rebased again (42.30 KB, patch)
2016-10-14 08:54 PDT, Carlos Garcia Campos
no flags
Fix the build (42.33 KB, patch)
2016-10-14 09:01 PDT, Carlos Garcia Campos
mcatanzaro: review+
Patch for landing (42.23 KB, patch)
2016-11-10 01:18 PST, Carlos Garcia Campos
no flags
Carlos Garcia Campos
Comment 1 2016-08-03 05:08:08 PDT
Created attachment 285219 [details] WIP patch It's actually finished, it's WIP because it needs the XCode changes, but it would be great if could be reviewed before I find someone who add the new files for me. This should fix all layergin violations in MemoryPressureHandler.
Andreas Kling
Comment 2 2016-08-05 07:40:46 PDT
Comment on attachment 285219 [details] WIP patch View in context: https://bugs.webkit.org/attachment.cgi?id=285219&action=review This is quite nice :) > Source/WebKit/mac/WebView/WebView.mm:1127 > + notify_register_dispatch("com.apple.WebKit.fullGC", &dummy, dispatch_get_main_queue(), ^(int) { > + GCController::singleton().garbageCollectNow(); > + }); > + notify_register_dispatch("com.apple.WebKit.deleteAllCode", &dummy, dispatch_get_main_queue(), ^(int) { > + GCController::singleton().deleteAllCode(); > + GCController::singleton().garbageCollectNow(); > + }); This code is duplicated in both WebKit1 and WebKit2. If a process uses both, it will hook 2 separate callbacks to each notification name, effectively making the callbacks execute twice.
Carlos Garcia Campos
Comment 3 2016-09-19 05:37:22 PDT
(In reply to comment #2) > Comment on attachment 285219 [details] > WIP patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=285219&action=review > > This is quite nice :) Thanks, I still need help with the XCode changes. > > Source/WebKit/mac/WebView/WebView.mm:1127 > > + notify_register_dispatch("com.apple.WebKit.fullGC", &dummy, dispatch_get_main_queue(), ^(int) { > > + GCController::singleton().garbageCollectNow(); > > + }); > > + notify_register_dispatch("com.apple.WebKit.deleteAllCode", &dummy, dispatch_get_main_queue(), ^(int) { > > + GCController::singleton().deleteAllCode(); > > + GCController::singleton().garbageCollectNow(); > > + }); > > This code is duplicated in both WebKit1 and WebKit2. If a process uses both, > it will hook 2 separate callbacks to each notification name, effectively > making the callbacks execute twice. Is it really possible to use WebKit1 and WebKit2 from the same process? The WebKit2 code is in the web process initialization, so even if an application uses both, the UI process would install the WebKit1 callbacks and the web processes the WebKit2 ones. So, I'm not sure this is a problem. It would only be a problem if webkit1 can be used from a webkit2 injected bundle or something like that.
Carlos Garcia Campos
Comment 4 2016-09-19 05:57:57 PDT
Created attachment 289224 [details] Rebased patch Patch rebased to apply on current trunk. Moved the notify callback registration to a common place in webcore and ensured they are only registered once.
youenn fablet
Comment 5 2016-10-14 02:35:13 PDT
Patch no longer applies...
Carlos Garcia Campos
Comment 6 2016-10-14 02:41:02 PDT
Let me rebase it
Carlos Garcia Campos
Comment 7 2016-10-14 02:48:13 PDT
Created attachment 291604 [details] Rebased patch
Carlos Garcia Campos
Comment 8 2016-10-14 03:32:36 PDT
Created attachment 291607 [details] Patch Now with the files added to XCode, thanks youenn!
Carlos Garcia Campos
Comment 9 2016-10-14 04:06:01 PDT
Created attachment 291610 [details] Try to fix mac build
Carlos Garcia Campos
Comment 10 2016-10-14 04:41:51 PDT
/Volumes/Data/EWS/WebKit/Source/WebKit/mac/WebView/WebView.mm:160:9: fatal error: 'WebCore/MemoryRelease.h' file not found Do I need to do anything special for wk1 to find that WebCore header?
youenn fablet
Comment 11 2016-10-14 04:47:26 PDT
Maybe marking it as Private in Xcode file. Edit the pbxproj file and add something like "settings = {ATTRIBUTES = (Private, );" to one of the added line for MemoryRelease.h that also has "fileRef" in it.
Carlos Garcia Campos
Comment 12 2016-10-14 04:55:43 PDT
Created attachment 291618 [details] Try to fix mac build Marking the header as private
Carlos Garcia Campos
Comment 13 2016-10-14 04:56:11 PDT
(In reply to comment #11) > Maybe marking it as Private in Xcode file. > Edit the pbxproj file and add something like > "settings = {ATTRIBUTES = (Private, );" > to one of the added line for MemoryRelease.h that also has "fileRef" in it. Trying that, thanks again.
Carlos Garcia Campos
Comment 14 2016-10-14 05:28:39 PDT
Created attachment 291621 [details] Try to fix mac build
Carlos Garcia Campos
Comment 15 2016-10-14 05:48:52 PDT
Created attachment 291624 [details] Try to fix mac build
Carlos Garcia Campos
Comment 16 2016-10-14 06:11:36 PDT
Created attachment 291625 [details] Try to fix mac build
Carlos Garcia Campos
Comment 17 2016-10-14 06:27:08 PDT
Created attachment 291627 [details] Try to fix mac build
Build Bot
Comment 18 2016-10-14 07:20:13 PDT
Comment on attachment 291627 [details] Try to fix mac build Attachment 291627 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/2284493 Number of test failures exceeded the failure limit.
Build Bot
Comment 19 2016-10-14 07:20:18 PDT
Created attachment 291632 [details] Archive of layout-test-results from ews113 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews113 Port: mac-yosemite Platform: Mac OS X 10.10.5
Carlos Garcia Campos
Comment 20 2016-10-14 08:42:23 PDT
Created attachment 291636 [details] Try to fix wk1 crashes Ensure we install the memory pressure only once in WebKit1 mac to avoid hitting an assert.
Carlos Garcia Campos
Comment 21 2016-10-14 08:54:36 PDT
Created attachment 291637 [details] Rebased again
Carlos Garcia Campos
Comment 22 2016-10-14 09:01:50 PDT
Created attachment 291638 [details] Fix the build
Carlos Garcia Campos
Comment 23 2016-10-20 05:53:55 PDT
ping reviewers.
Darin Adler
Comment 24 2016-10-20 09:38:00 PDT
I think Andreas Kling or Anders Carlsson should review this.
Michael Catanzaro
Comment 25 2016-11-01 16:53:51 PDT
Comment on attachment 291638 [details] Fix the build View in context: https://bugs.webkit.org/attachment.cgi?id=291638&action=review Andreas liked the initial version of the patch (see comment #2), and I think not much has changed; I think we can count that as owner approval if there are not any objections. It looks like a good fix for these layering violations. A couple questions: > Source/WebCore/platform/MemoryPressureHandler.cpp:62 > + if (!m_lowMemoryHandler) > + return; Wouldn't an early return here be a bug? Shouldn't there be an assertion here? > Source/WebCore/platform/MemoryPressureHandler.h:173 > + void (^m_releaseMemoryBlock)() { nullptr }; I know this was here before, but... what is this???
Carlos Garcia Campos
Comment 26 2016-11-10 01:18:12 PST
Created attachment 294345 [details] Patch for landing
Carlos Garcia Campos
Comment 27 2016-11-10 06:27:42 PST
Alex Christensen
Comment 28 2016-11-10 18:35:12 PST
Comment on attachment 294345 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=294345&action=review > Source/WebCore/platform/MemoryPressureHandler.h:72 > ASSERT(!m_installed); I'm hitting this assertion now in debug Safari
Alex Christensen
Comment 29 2016-11-10 18:38:39 PST
We're calling WebInstallMemoryPressureHandler before [WebView initWithFrame:frameName:groupName:]
Michael Catanzaro
Comment 30 2016-11-10 18:47:08 PST
(In reply to comment #29) > We're calling WebInstallMemoryPressureHandler before [WebView > initWithFrame:frameName:groupName:] WebInstallMemoryPressureHandler only exists in WebKit1. Surely Safari is not using it?
Darin Adler
Comment 31 2016-11-10 20:39:33 PST
(In reply to comment #30) > (In reply to comment #29) > > We're calling WebInstallMemoryPressureHandler before [WebView > > initWithFrame:frameName:groupName:] > > WebInstallMemoryPressureHandler only exists in WebKit1. Surely Safari is not > using it? Safari uses both legacy WebKit (WebKit1) and modern WebKit (WebKit2). Some day it might get to the point where it has no dependency on legacy WebKit, but at the moment it still uses both.
Alex Christensen
Comment 32 2016-11-10 22:19:44 PST
I fixed it in http://trac.webkit.org/changeset/208580 Carlos and Michael, could you look at that change and make sure I'm not abusing your work?
Carlos Garcia Campos
Comment 33 2016-11-10 22:57:21 PST
(In reply to comment #32) > I fixed it in http://trac.webkit.org/changeset/208580 > Carlos and Michael, could you look at that change and make sure I'm not > abusing your work? Great, thanks for fixing it without rolling out the patch :-)
Michael Catanzaro
Comment 34 2016-11-11 04:38:17 PST
(In reply to comment #31) > Safari uses both legacy WebKit (WebKit1) and modern WebKit (WebKit2). Some > day it might get to the point where it has no dependency on legacy WebKit, > but at the moment it still uses both. Anywhere I can learn about why Safari still needs legacy WebKit and what it uses it for? That's really surprising to me and I'm curious!
Darin Adler
Comment 35 2016-11-11 15:18:40 PST
(In reply to comment #34) > (In reply to comment #31) > > Safari uses both legacy WebKit (WebKit1) and modern WebKit (WebKit2). Some > > day it might get to the point where it has no dependency on legacy WebKit, > > but at the moment it still uses both. > > Anywhere I can learn about why Safari still needs legacy WebKit and what it > uses it for? That's really surprising to me and I'm curious! I don’t think there is anywhere to learn that, but I am willing to disclose a little bit: At some point in the recent past, there was some use of legacy WebKit in some of the Safari Browser Extension support. Also, keep in mind that WebKit is a system framework on macOS; Safari can invoke some other macOS framework and nothing prevents that framework from using some bit of WebKit API for some task.
Michael Catanzaro
Comment 36 2016-12-19 21:01:53 PST
(Note: I've removed this patch from the list of proposed backports for 2.14 because it is a huge refactor. r208975 can still easily be backported, the code just moved from one file to another.) (In reply to comment #35) > I don’t think there is anywhere to learn that, but I am willing to disclose > a little bit: At some point in the recent past, there was some use of legacy > WebKit in some of the Safari Browser Extension support. > > Also, keep in mind that WebKit is a system framework on macOS; Safari can > invoke some other macOS framework and nothing prevents that framework from > using some bit of WebKit API for some task. Interesting!
Note You need to log in before you can comment on or make changes to this bug.