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

[Phil Bouchard]

On 07/06/2017 11:10 AM, Thiago Macieira wrote:
> 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.
>
> 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.

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.

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.

>> Or perhaps it should be a choice on whether the user wants to use the
>> garbage collector or root_ptr and he can decide by himself what is more
>> convenient for him according to his context.
>
> Sure. A choice of different engines, completely different APIs. If the user
> wants root_ptr, they can write their application using something other than
> QtQml. Nothing is stopping them from it.

Well I'm here to help Qt because I know quite well that WebKit for 
Wayland is the number 1 rendering engine and Javascript processor.  The 
problem with WebKit is that their garbage collector is inlaid with the 
code of WebKit, making it impossible to throw away the garbage 
collector.  And WebKit is an engineering product which means they are 
not interested into innovative theoretical libraries that just came out 
of the oven.

On the other hand it seems quite possible to upgrade or change the 
garbage collector in the Qt library and if we analyze the integration of 
root_ptr carefully then it should be done quickly.

>>>> - The objects are destroyed is the exact reverse order they were
>>>> constructed thus this will help debugging.
>>>
>>> But unnecessary, since the order they are constructed is irrelevant. The
>>> JS
>>> order matters.
>>
>> It's a plus.
>
> No, it isn't. The JS order is the important order. If you do it outsiide of
> the order that the language requires, then it's just plain wrong.

What do you mean exactly by the JS order?  If you have a function:

function()
{
     var objA =
     {
         prop: "foo",
         next: null
     };

     var objB =
     {
         prop: "foo",
         prev: null
     };

     objA.next = objB;
     objB.prev = objA;  // cycle
}

Then the order of destruction of var objA and objB is undefined in 
Javascript whereas root_ptr guarantees that objB will get destroyed 
before objA.  But there is rule regarding the order of destruction in 
Javascript already so we can't break anything.

> Please explain to me how root_ptr works for a garbage-collected language
> interpreter. Particularly if you have any studies on a JS interpreter.

Javacript is not very complicated to understand for people who wrote 
interpreters.  I happen to write a parser for mathematical equations in 
my scientific calculator using my good old friendly mutable_ptr:
http://www.fornux.com

And it's the same for Javascript except that they have more advanced 
standards.

Regarding root_ptr and Javascript then all we have to do is to define 
exactly where isolated entities are given birth and die.  In other words 
we just need to know where root_ptr will be put.  Do you agree that an 
HTML page and a QML window represent exactly this?  In the latter the 
only way a QML window can communicate with the outside world is by 
sending a signal (if you write directly in a parent window then that is 
bad programming and it shouldn't be allowed).

All that is required here is to analyze the situation carefully and 
we'll have a faster Javascript engine instead of just trying to patch 
the existing GC.  And the GC should be an abstraction we can replace and 
it shouldn't be part of the definition of Javascript.


Thanks,
-Phil