A big V8/DOM memory leak I was chasing down turns out to be not a real
leak, it's just that it takes five full GCs after closing a document
for its resources to be freed. I'd been getting bored after two GCs,
so it wasn't till Ivan mentioned the stickiness of the generated-
function caches that I thought to turn it up to 5.
This still seems like an opportunity for optimization — the
WebCore::Document and WebCore::DOMWindow can have a lot of stuff
hanging off of them, so we should try to clean them up more quickly
after a same-process child tab closes.
The sticky reference is actually to the v8::Context. The DOM objects
hang on because they're pointed to by that context's globals. So if
the context's globals could be cleared when Chrome's V8Proxy disposes
the context, the DOM objects should go away at the next GC.
Good news: There is a v8::Context::DetachGlobal method that appears to
separate the globals from the context. Bad news: it doesn't appear to
do what I expected it to. After it's called the context still seems to
have a reference to the globals, because they still don't go away
until later when the context is collected.
I looked at the implementation, Bootstrapper::DetachGlobal
(bootstrapper.cc:361) but I don't really understand what it's doing.
The context internally has both a global() and a global_proxy()
object, and this method seems to detach the latter but not the former.
From the way they're created it looks like the global() points to the
global_proxy(), explaining why there's still a connection after
detaching.
Is there a way I can sever the relationship from the context to the
globals? Would it require adding a new V8 API method similar to
DetachGlobal?
(I did find one approach that sort of works: iterating over the global
object's properties and removing them all. Unfortunately I can't use
this because in some cases the V8Proxy requires the global object to
stay intact after disposing the context, so it can be used with a new
context, and at the point where the context is disposed I don't know
whether that's going to happen or not.)
Thanks,
—Jens
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
