Hi Zoltan,
On Sep 29, 2009, at 12:39 PM, Zoltan Herczeg wrote:
Hi Kevin,
WebKit approach is NOT to free memory before quit to make the quit
process
as fast as possible. The memory manager should free the unfreed
objects.
However, this approach makes really hard to find the "real" leaks
(which
are unreferenced objects).
In my experince the unfreed (non-leak) objects come from several
sources:
- JavaScriptCore garbage collector is not called before quit
- Caches are not cleared before quit
The previous two are performed by QtLauncher in debug mode. See
WebKit/qt/QtLauncher/main.cpp launcherMain()
- In case of workers, the gc() does not called for each worker
threads
when the application quits. The JavaScript threads are simply aborted.
- Global objects are not freed at all. There was an attempt to free
them
(see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not
worth
to continue that work, although it helped to find leaks such as this:
https://bugs.webkit.org/show_bug.cgi?id=29295
The remaining unfreed objects are possible leaks. Many of them are
probably port specific (not all port maintainers have resources to
keep
leak hunters).
Thanks for the detailed response, this makes things very clear! :-) (&
thanks to Darin for his info about leak checkers) I guess I didn't
really expect things to work this way in debug mode as it seems to me
RefCountedLeakChecker pretty much needs those resources to be freed in
order to provide useful leak reports. In any case, I've been thinking
about adding some APIs to manage the cache to wxWebKit and now I've
got even more of an incentive to code something up. :-)
Thanks,
Kevin
Zoltan
Hi all,
For a while, ports like wx and Win/Cairo have been seeing various
leaks reported on shutdown, but at least on Mac I've been unable to
see these leaks using memory leak checkers like the one in
Instruments, so I decided to poke into the code a bit more and try to
understand what's going on a bit better.
What I found was that the reported object leaks were pretty much all
related to objects that JSC has references to. Changing
~ScriptController to do a garbageCollectNow() instead of
garbageCollectSoon(), for example, drastically reduced the number of
reported leaks, cleaning up all the CachedResource leaks and almost
all the WebCoreNode leaks. The remaining leaks were almost all
JSC::Structure objects. I've been digging through the code to try and
find the place where these JSC objects are finally deleted, but I
haven't found anyplace obvious in the code, neither in common code
nor
in the ports' code.
My question is, is there somewhere these objects are being deleted on
final shutdown that apparently happens after the leaks are reported,
or does WebKit have assumptions such as that all still running timers
must fire before final shutdown that ports such as ours are not
honoring? (e.g. in my tests garbageCollectSoon() does not end up
firing the callback because the app shuts down too fast.)
Thanks,
Kevin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
