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

[Thiago Macieira]

On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote:
> > 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.

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.

> 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.

Sorry, not workable.

> 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?

> > 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.

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.

> 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?

> 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.

> > 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.

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.

By the way, how does it break the cycle?

> 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?  

I do not. See above.

> 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.

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?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center