[Development] Qt 5.9's new garbage collector documentation? + root_ptr

[Phil Bouchard]

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