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

[Phil Bouchard]

On 07/06/2017 10:57 PM, Thiago Macieira wrote:
> On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote:
>>
>> 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.
>
> That is too late. QML pages are meant to be open for a long time, like the
> application's main screen. There are even web pages that operate like that
> today -- I certainly have a few always-interacting and always-on webpages open
> on my Chrome. If the garbage collector did not run, I'm sure the memory use
> would be higher.

Well then you scale down the usage of root_ptr to containers like a 
listview which is constantly refreshed for most applications.  It's the 
same with a Gmail webpage which has a listview that is constantly 
refreshed because you keep pressing on the Inbox button to refresh it.

>> 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.
>
> How well does root_ptr operate when there are cyclic references? JavaScript
> objects can refer to each other, so how do you propose the engine handle that
> case?

It's very easy.  Every time a node_ptr is created, it enlists the 
pointee object to its associated root_ptr.  When the root_ptr is 
destroyed then all associated objects in that list are destroyed as 
well.  This is how cyclic references are guaranteed to be destroyed 
deterministically.

>> 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.
>
> Your motivation is at odds with your objective. We don't maintain WebKit.
> There's barely any participation from us at all.
>
> And the QML engine is neither WebKit's (JSC) nor Blink's (V8). It's our own.

Sorry I meant that I'm here to help Qt to have a better product than the 
competition.

>> 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.
>
> Nor are we. Show us that it working and we'll take a chance. A theoretical
> solution with no real-life implementation is not for us.
>
> Have you impemented any engine for garbage collected languages using root_ptr?
> How well does root_ptr work with the Python engine? Or a Java VM? Lua? Ruby?
> Any scripting language VMs implemented using it?

No but it works well with neural networks which I think is a good 
example of a worse case situation:
https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp

>> 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.
>
> Again, QtQml engine is really tied to JavaScript. I don't think you can get
> out of having a garbage collector at all.

I guess we could ask Qt's garbage collector experts.

> If the order of destruction according to the language is undefined, then the
> order in which root_ptr destroys it is not relevant and it can't be considered
> a plus. In fact, having it deterministic could be a negative asset, since
> someone writing this code will never be exposed to undefinedness of their code.

I certainly think it's a plus for debugging purposes.  And I fail to 
understand the advantage of the undefinedness of the code.

> By the way, how does it break the cycle?

Like I was saying before, node_ptr enlists each pointee object to the 
associated root_ptr and when the root_ptr is destroyed then everything 
gets wiped out.

>> 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.
>
> No, all that is required is that someone actually write the code. Are you
> volunteering or do you have anyone who understands root_ptr that is?

Nobody really understands root_ptr despite all the documentation I 
wrote.  I think the only one most familiar with it is Peter Dimov; the 
author of shared_ptr.

Fortunately I am almost done with the following projects:
http://www.finitetheory.com
https://www.actatabula.com

So I am volunteering but I can't compile the whole Qt library on my 
laptop so I'll need stripped out packages and some Q&A so that I can 
first understand what is so special with the GC.


Thanks,
-Phil