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