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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
