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