Bug 188399 - Web Inspector: Consider raising the 4gb process memory limit for WebInspector process
Summary: Web Inspector: Consider raising the 4gb process memory limit for WebInspector...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-08-07 19:31 PDT by Saam Barati
Modified: 2020-08-27 14:13 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Saam Barati 2018-08-07 19:31:11 PDT
I ran into this limit a few times when taking heap snapshots of large heaps.
Comment 1 Joseph Pecoraro 2018-08-08 15:14:06 PDT
In WebKit the Web Inspector frontend page is just a WebPageProxy:

    void WebInspectorProxy::createFrontendPage()
    {
        if (m_inspectorPage)
            return;

        m_inspectorPage = platformCreateFrontendPage();
        ...
        trackInspectorPage(m_inspectorPage);
        ...
    }


However these inspector frontend pages are put into special WebProcessPools meant for only Inspector Pages:

    WebProcessPool& inspectorProcessPool(unsigned inspectionLevel)
    {
        // Having our own process pool removes us from the main process pool and
        // guarantees no process sharing for our user interface.
        WebProcessPool*& pool = (inspectionLevel == 1) ? s_mainInspectorProcessPool : s_nestedInspectorProcessPool;
        if (!pool) {
            auto configuration = API::ProcessPoolConfiguration::createWithLegacyOptions();
            pool = &WebProcessPool::create(configuration.get()).leakRef();
        }
        return *pool;
    }

This makes me think that if we can set a bit on the WebProcessProxy / WebProcess that says "You're a Debugger Process".

Then when the first WebPage is created in the process pool it could propagate the property to the pressure handler:

    MemoryPressureHandler::singleton()->setDebuggerProcess();

This could then raise / affect the limit.
Comment 2 BJ Burg 2018-08-08 16:22:01 PDT
Joe's investigation sounds like a good plan.

Is there any reasonable way to test this without screwing up bots? Obviously we can try to take a huge heap snapshot, but considering how slow bots are already compared to dev boxes, I'm not sure a test like this would be stable or useful.
Comment 3 Alexey Proskuryakov 2018-08-08 16:55:47 PDT
I'm also skeptical of testing that uses huge amounts of memory.
Comment 4 Radar WebKit Bug Importer 2020-08-27 14:13:40 PDT
<rdar://problem/67896698>