Bug 224155 - [GPUP] Purge renderer resources after 2D canvas and media features become inactive
Summary: [GPUP] Purge renderer resources after 2D canvas and media features become ina...
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kimmo Kinnunen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-04-03 11:35 PDT by Peng Liu
Modified: 2021-04-18 22:44 PDT (History)
10 users (show)

See Also:


Attachments
WIP patch (2.60 KB, patch)
2021-04-03 11:39 PDT, Peng Liu
no flags Details | Formatted Diff | Diff
WIP patch (3.83 KB, patch)
2021-04-03 11:46 PDT, Peng Liu
no flags Details | Formatted Diff | Diff
Patch (5.79 KB, patch)
2021-04-05 11:53 PDT, Peng Liu
no flags Details | Formatted Diff | Diff
Patch (6.38 KB, patch)
2021-04-05 12:54 PDT, Peng Liu
no flags Details | Formatted Diff | Diff
Patch, not tested (3.66 KB, patch)
2021-04-07 03:30 PDT, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff
Patch, not tested (3.66 KB, patch)
2021-04-07 03:30 PDT, Kimmo Kinnunen
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch, not tested (3.67 KB, patch)
2021-04-07 04:31 PDT, Kimmo Kinnunen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peng Liu 2021-04-03 11:35:14 PDT
[GPUP] Purge renderer resources after 2D canvas and media features become inactive
Comment 1 Peng Liu 2021-04-03 11:39:37 PDT
Created attachment 425102 [details]
WIP patch
Comment 2 Peng Liu 2021-04-03 11:46:53 PDT
Created attachment 425103 [details]
WIP patch
Comment 3 Radar WebKit Bug Importer 2021-04-04 22:18:25 PDT
<rdar://problem/76205859>
Comment 4 Jon Lee 2021-04-05 10:48:04 PDT
rdar://76166141
Comment 5 Peng Liu 2021-04-05 11:53:47 PDT
Created attachment 425180 [details]
Patch
Comment 6 Simon Fraser (smfr) 2021-04-05 12:00:02 PDT
Comment on attachment 425180 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=425180&action=review

> Source/WebKit/GPUProcess/graphics/ScopedRenderingResourcesRequestCocoa.mm:73
> +    [[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationDidEnterBackgroundNotification object:nil userInfo:nil];

Rather than softlink UIKIt, you can use use the NSString* version of these: @"UIApplicationDidEnterBackgroundNotification" (please check the actual string).

> Source/WebKit/GPUProcess/ios/GPUProcessIOS.mm:54
> +    int token;
> +    notify_register_dispatch("org.WebKit.GPUProcessPurgeUnusedResources", &token, dispatch_get_main_queue(), ^(int) {
> +        [[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationDidEnterBackgroundNotification object:nil userInfo:nil];
> +        }
> +    );
> +
> +    [[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationDidFinishLaunchingNotification object:nil userInfo:nil];

Do we want this? Should we instead respond to "org.WebKit.lowMemory" which the tests already send?
Comment 7 Peng Liu 2021-04-05 12:29:06 PDT
Comment on attachment 425180 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=425180&action=review

>> Source/WebKit/GPUProcess/ios/GPUProcessIOS.mm:54
>> +    [[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationDidFinishLaunchingNotification object:nil userInfo:nil];
> 
> Do we want this? Should we instead respond to "org.WebKit.lowMemory" which the tests already send?

I suppose you referred to the line of `notify_register_dispatch`? Yes, sounds a good idea to do it in response of "org.WebKit.lowMemory".
Comment 8 Peng Liu 2021-04-05 12:54:24 PDT
Created attachment 425191 [details]
Patch
Comment 9 Peng Liu 2021-04-05 13:06:06 PDT
Comment on attachment 425180 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=425180&action=review

>> Source/WebKit/GPUProcess/graphics/ScopedRenderingResourcesRequestCocoa.mm:73
>> +    [[NSNotificationCenter defaultCenter] postNotificationName:UIApplicationDidEnterBackgroundNotification object:nil userInfo:nil];
> 
> Rather than softlink UIKIt, you can use use the NSString* version of these: @"UIApplicationDidEnterBackgroundNotification" (please check the actual string).

Fixed.
Comment 10 Kimmo Kinnunen 2021-04-05 23:03:18 PDT
Comment on attachment 425191 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=425191&action=review

I think there's couple of checks that still need taken care of? Ping me offline unless you know the cases and have taken care of them.

> Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm:127
> +        [[NSNotificationCenter defaultCenter] postNotificationName:@"UIApplicationDidEnterBackgroundNotification" object:nil userInfo:nil];

This causes wrong counts, e.g. the receivers think the app is in the background even though it might be in the foreground.
How/where do we undo the action done here?

> Source/WebKit/GPUProcess/graphics/ScopedRenderingResourcesRequest.h:76
> +        if (!s_requests)

I don't think this sort of thing is thread-safe?

> Source/WebKit/GPUProcess/graphics/ScopedRenderingResourcesRequestCocoa.mm:72
> +    [[NSNotificationCenter defaultCenter] postNotificationName:@"UIApplicationDidEnterBackgroundNotification" object:nil userInfo:nil];

I wonder if nsnotificationchenter posting is thread safe?
Comment 11 Peng Liu 2021-04-06 12:08:46 PDT
Some Core Animation states need to be taken care of properly. Over to Kimmo. :-)
Comment 12 Kimmo Kinnunen 2021-04-07 03:30:02 PDT
Created attachment 425375 [details]
Patch, not tested
Comment 13 Kimmo Kinnunen 2021-04-07 03:30:58 PDT
Created attachment 425376 [details]
Patch, not tested
Comment 14 Kimmo Kinnunen 2021-04-07 04:31:34 PDT
Created attachment 425380 [details]
Patch, not tested
Comment 15 Darin Adler 2021-04-17 21:38:47 PDT
Do you want someone to review your untested patch? Normally we’d want to review it after it’s tested.
Comment 16 Chris Dumez 2021-04-17 22:19:18 PDT
(In reply to Darin Adler from comment #15)
> Do you want someone to review your untested patch? Normally we’d want to
> review it after it’s tested.

I think the decision during the last GPUProcess sync-up was to A/B test this patch after I landed the GPUProcess idle exit change. My patch has landed now. Kimmo, do you need help scheduling the A/B test?