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

Thiago Macieira thiago.macieira at intel.com
Thu Jul 6 17:10:42 CEST 2017


On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote:
> On 07/06/2017 01:01 AM, Thiago Macieira wrote:
> > On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote:
> >> - Well with root_ptr the behavior is 100% predictable thus you won't
> >> have these rendering lags at random times.
> > 
> > So explain to me how the QML engine should collect JS items that have gone
> > unused and unreferenced during the exection. Predictable execution isn't
> > good enough if it involves never garbage collecting and thus using a lot
> > more memory.
> 
> 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.

> We want the fastest executable in the end given an extensible level of
> complexity of the executable.  If the garbage collector stops you from
> doing that then there's is no light at the end of the tunnel.

Agreed. People should stop using *languages* that require this type of garbage 
collector. But until that happens, we'll be forced to have GCs.

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

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

Please explain to me how root_ptr works for a garbage-collected language 
interpreter. Particularly if you have any studies on a JS interpreter.

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




More information about the Development mailing list