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 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
Details
Formatted Diff
Diff
Rebased patch
(35.50 KB, patch)
2016-09-19 05:57 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Rebased patch
(35.49 KB, patch)
2016-10-14 02:48 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Patch
(41.34 KB, patch)
2016-10-14 03:32 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.51 KB, patch)
2016-10-14 04:06 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.55 KB, patch)
2016-10-14 04:55 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.54 KB, patch)
2016-10-14 05:28 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.57 KB, patch)
2016-10-14 05:48 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.57 KB, patch)
2016-10-14 06:11 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Try to fix mac build
(41.88 KB, patch)
2016-10-14 06:27 PDT
,
Carlos Garcia Campos
buildbot
: commit-queue-
Details
Formatted Diff
Diff
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
Details
Try to fix wk1 crashes
(42.00 KB, patch)
2016-10-14 08:42 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Rebased again
(42.30 KB, patch)
2016-10-14 08:54 PDT
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Fix the build
(42.33 KB, patch)
2016-10-14 09:01 PDT
,
Carlos Garcia Campos
mcatanzaro
: review+
Details
Formatted Diff
Diff
Patch for landing
(42.23 KB, patch)
2016-11-10 01:18 PST
,
Carlos Garcia Campos
no flags
Details
Formatted Diff
Diff
Show Obsolete
(14)
View All
Add attachment
proposed patch, testcase, etc.
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
Committed
r208534
: <
http://trac.webkit.org/changeset/208534
>
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.
Top of Page
Format For Printing
XML
Clone This Bug