[Development] Qt 5.9's new garbage collector documentation? + root_ptr
Phil Bouchard
philippeb8 at gmail.com
Fri Jul 7 05:48:27 CEST 2017
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
More information about the Development
mailing list