[Development] Qt 5.9's new garbage collector documentation? + root_ptr
Phil Bouchard
philippeb8 at gmail.com
Fri Jul 7 13:32:38 CEST 2017
On 07/07/2017 04:39 AM, Edward Welbourne wrote:
> Phil Bouchard (7 July 2017 04:15)
>>
>> Anything that goes in that HTML page or QML window we don't care. The
>> reference counted property of root_ptr (node_ptr) will handle it and
>> the associated root_ptr will clean up the mess when it is destroyed.
>
> You'd need to apply root_ptr on a finer granularity than the top-level
> HTML page or QML window. For example, when a function gets called in an
> interpreted language, there's something like a "stack frame" created,
> within the context of which the function executes, finally returning
> some value to the caller. To complicate life, that frame may survive
> the return as a closure (e.g. if the return values is a function object
> that references locals of the frame). In C++, exiting a scope (which
> corresponds to such a frame) calls destructors on all the objects
> declared in the scope; but that doesn't happen in JavaScript, which
> relies on the garbage-collector to catch those objects after they've
> passed out of scope. If you can convincingly exhibit an interpreted
> language using root_ptr for each of those frames, without causing
> breakage (you'll need to make sure the returned value can't end up
> holding any references to values owned by that frame; and you'll need to
> interact correctly with closures), you'll have a more convincing case
> for your innovation.
>
> As long as you pitch your idea in terms of the top-level HTML page or
> QML window, you aren't convincing - because we *know* that'll leave huge
> amounts of transiently-used memory that doesn't get released until the
> page or window is closed, which is *far* too late. Show that you can
> make it work at the level where it would actually reclaim memory sooner
> than a garbage collector would. Then folk might listen.
Ok thanks for the detailed analysis. If there is one root_ptr per
Javascript function then all local variables are guaranteed to be
destroyed. And closures aren't too big of a deal either because child
objects can easily refer to their parent.
But returning local variables might need some work on root_ptr such as
"unlisting" the variable from one set in order to "enlist" it to the
parent set. I also will need to remove the ability from root_ptr to
"unify" sets when one of its node_ptr refers to an object from another set.
If I can do that then there is no need to create a new language.
Thanks,
-Phil
More information about the Development
mailing list