V8::GlobalHandles keeps growing in size keeping Facebook open |
||||||
Issue descriptionI kept Facebook open for 4 days and traced all malloc allocations. The GlobalHanldes grew in size by 3MB. Stack trace of the allocation: ↳ƒv8::internal::Builtin_Impl_HandleApiCall 8,686.4 KiB ↳ƒv8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper 8,686.4 KiB ↳ƒv8::internal::FunctionCallbackArguments::Call 8,686.4 KiB ↳ƒblink::DOMWindowV8Internal::setTimeout1Method 8,686.4 KiB ↳ƒblink::DOMWindowTimers::setTimeout 3,022.7 KiB ↳ƒblink::ScheduledAction::create 3,022.7 KiB ↳ƒblink::ScheduledAction::ScheduledAction 3,022.7 KiB ↳ƒv8::V8::GlobalizeReference 3,022.7 KiB ↳ƒv8::internal::GlobalHandles::Create(v8::internal::Object*)
,
Jan 17 2017
,
Jan 18 2017
If the timeouts where for a long duration and many where canceled then https://codereview.chromium.org/2637463002 should help. Getting a trace with renderer.scheduler.debug enabled would let us know if cancelled tasks are the problem or not.
,
Jan 19 2017
,
Jan 19 2017
Stack trace is similar to issue 671489 which I just recorded using a debug build. Basically what happens is that the inspector keeps strong references (read: global handles) to printed messages.
,
Jan 23 2017
This is a bad bug that needs to be fixed but is not a recent regression in memory use (based on comments in Issue 671489 )?
,
Jan 26 2017
Re 3: Trace with renderer.scheduler.debug gives no events at all in the trace.
,
Jan 26 2017
renderer.scheduler.debug generates huge traces (especially if there are a lot of cancelled tasks in the queues) so you can only record a couple of seconds worth usually :P
,
Jan 27 2017
Re 8: No i can see that no events are being added to the trace. The buffer is always 0 and viewer shows nothing. Anyway, after the fix I tried running the same and it looks like V8::GlobalHandles no longer allocates so much memory. I will mark this fixed. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ssid@chromium.org
, Jan 17 2017