I looked at this problem with Matt today. First of all we noticed that running his test case the heap kept growing as the content scripts were loaded, even though each content script's context was being disposed before loading the next script triggering a GC before loading the next content script as Matt described. It turns out that the Chrome extension setup adds a unload handler which survives until the next run through the event loop. This event handler keeps the context alive during the run of this test. The increase in heap size caused the GC times to increase as we went along executing new content scripts. This is something for the extensions team to address.
Each mark-sweep cycle did take about 10ms once the leak was removed, this to me sounds still a bit high for an essentially empty heap. We should take a hard look at where we spend the time here, and where we spend the time in GC in general. Also, when running with a non-trivial page (unlike the test case) I expect the heap to be larger, causing longer GC times. This will be causing the GC on context creation to have more impact. On the other hand, the content script is likely to have allocated a non-trivial amount memory that the benefit of GC'ing its context is useful. The effect is that for some users the GC between content scripts will be a benefit and for some it will be a loss, currently I have no idea which side of the dividing line the majority of our users will come in. The current test case does not measure real user behavior as both the page and the scripts are trivial. Additional inline comments added below. Cheers, -Ivan On Wed, Sep 23, 2009 at 06:09, Mads Sig Ager <[email protected]> wrote: > > I will have a look at this. The heuristic is very bad for this > situation and we will look into what we can do. > > Independently of this heuristic, creating contexts is not exactly > cheap, but I guess you do need to have complete separation of those > scripts? True, the scripts have to be completely separated from each other. > Cheers, -- Mads > > On Wed, Sep 23, 2009 at 1:23 PM, Vitaly Repeshko <[email protected]> wrote: >> >> Can we enhance the heuristic to require that a certain number of >> allocations in the old context must have been made to force a GC? This is a non-starter. A meaningful content script (and not just Matt's test case) will run some amount of JavaScript which is bound to allocate some objects. Additionally, all the V8 extensions being added to the context by the Chrome extension system will already allocate numerous objects. Also you do not ever want to get in the way of allocation speed, especially if the only benefit is for some edge case in the heuristic. >> >> >> -- Vitaly >> >> On Wed, Sep 23, 2009 at 11:38 AM, Darin Fisher <[email protected]> wrote: >>> What can we do about the negative performance impact this is having on >>> chrome extensions? >>> -Darin >>> >>> On Tue, Sep 22, 2009 at 12:57 PM, Erik Corry <[email protected]> wrote: >>>> >>>> >>>> 2009/9/22 Matt Perry <[email protected]> >>>>> >>>>> First, my question: what is the reason for the call >>>>> to i::Heap::CollectAllGarbageIfContextDisposed() in v8::Context::New? Is >>>>> it >>>>> just a heuristic that can be removed? Or can we maybe add an API to >>>>> disable >>>>> this in some cases? >>>> >>>> It's a heuristic. The idea is that when you navigate to a new page you >>>> will destroy a series of contexts (one per iframe) and then create a new >>>> context for the new main page. This is a good time to GC because it helps >>>> clear up the DOM nodes from the old page. >>>> >>>>> >>>>> The Chrome extension system introduces a feature called content scripts, >>>>> which allows you to run scripts in a new Context with a handle to the DOM >>>>> window of a target frame. The way this is implemented seems to trigger a >>>>> pathological case in v8::Context::New, causing more GCs than necessary. >>>>> What happens is that content scripts create short-lived Contexts, where >>>>> we create the Context, run some script, and immediately Dispose of it. The >>>>> call to Dispose sets a flag in v8 which causes the next call to >>>>> v8::Context::New to trigger a GC. This means that any time 2+ content >>>>> scripts are run in a given process, we do a GC, slowing down page load. >>>>> You can see the effect of running 50 content scripts on Chrome's startup >>>>> here: http://build.chromium.org/buildbot/perf/xp-release/startup/report.html?history=20 (the >>>>> top green line). If I comment out the call >>>>> to i::Heap::CollectAllGarbageIfContextDisposed(), the startup time for >>>>> that >>>>> test is cut in half. >>>>> >>>> >>>> >>>> >>>> -- >>>> Erik Corry, Software Engineer >>>> Google Denmark ApS. CVR nr. 28 86 69 84 >>>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen >>>> K, Denmark. >>>> >>>> >>> >>> >>> > >>> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
