On Jul 27, 2009, at 12:06 PM, Zoltan Herczeg wrote:
Hi,
by default, gc::collect() is triggered by a timer at regular
intervals. In
QtLauncher, gc::collect() is not called in any other way, so the
remaining
JS objects cause memory leaks when QtLauncher exits. Although this
approach may not be considered a bug, since the program soon quits, I
would be curious what other ports do before they return to the OS?
This
question is more important, if we want to use WebKit as a library:
in this
case the closing of the last WebKit frame may not necessary means
the end
of the current program.
Heap::collect() is called:
- By JavaScriptCore internal to GC allocation after some number of
allocations (which varies with the side of the heap).
- By WebCore on a one-shot zero-delay timer after after a frame is
navigated (clearing the global object) or after an item expires from
the back/forward cache
- In debug builds by WebKit (at least the mac version) immediately
when a WebView is closed during the app termination process.
Thus, after the last frame is closed there will be a garbage
collection unless the process exits before the timer has a chance to
run, and on Mac debug builds we make an extra effort to clean up for
the benefit of leak checking. (On release builds, we want to enable
the app to exit as fast as possible so we avoid all cleanup except for
flushing pending writes to disk.)
It's possible for GC to fail to completely clean up, because it is
partially conservative. The zero-delay timer is there to reduce the
risk of false stack references.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
