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

[Edward Welbourne]

On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote:
>>> It's all memory usage and bad programming habits vs execution speed.
>>> Why would you want to add objects that are never used?  A minimum
>>> programming skills set is required here.  You're saying the actual
>>> garbage collector should compensate for programming errors when I'm
>>> saying that's the programmer's responsibility.

That's not what garbage collection is about.  It's about objects that
are used transiently (e.g. in evaluating expressions) by some long-lived
entity (whose root_ptr thus won't go away any time soon).  After they've
been used, the garbage collector notices they're no longer in use and
tidies them away, well within the life-time of the entity that used
them.  Memory is thus released significantly earlier than it would be if
you rely on a root_ptr associated with that long-lived entity.

On 07/06/2017 11:10 AM, Thiago Macieira wrote:
>> I'm saying that the garbage collector has to compensate for language
>> requirements. Do you even know JavaScript? Temporary variables are
>> created all the time in the process of any algorithm; global state
>> variables could be cleared depending on usage; etc.
>>
>> The point is that the *language* requires us to have a garbage
>> collector to operate like that. So explain to me how root_ptr will
>> work in that context.

Phil Bouchard (7 July 2017 04:15)
> As you know in Javascript temporary unnamed variables from a primitive
> type are no different than local variables and even if global
> variables are not encouraged then they will be destroyed when the HTML
> page or QML window is killed.

This is far too late; the garbage collector gets much sooner after they
drop out of use, particularly when the HTML page or QML window *is* the
application, that's going to run for days.

> All root_ptr requires is to draw the line and isolate "entities" which
> have a birth and a certain death.  That is the case with HTML pages
> and QML windows and we can take advantage of that.
>
> 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.

	Eddy.