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

[Phil Bouchard]

Phil Bouchard <philippeb8 at gmail.com> wrote:
> 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
> 

Actually all that is needed to be done for that return value is to threat
that return value like an implicit parameter. Ex.:

var res;
function foo(res)
{
    res = 1;
}
alert((foo(res), res)); // outputs 1

Which is the same as:
function foo()
{
    return 1;
}
alert(foo()); // outputs 1


-Phil