Question regarding back-porting Lua 5.4 GC to 5.3

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Question regarding back-porting Lua 5.4 GC to 5.3

Dibyendu Majumdar
I am trying to understand whether to backport the 5.4 GC to 5.3 one
would need some of the other changes that were made or are these
orthogonal to the GC. In particular will the 5.4 GC work correctly if
the UpValue model was left as is in 5.3?

Thanks and Regards
Dibyendu
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding back-porting Lua 5.4 GC to 5.3

Roberto Ierusalimschy
> I am trying to understand whether to backport the 5.4 GC to 5.3 one
> would need some of the other changes that were made or are these
> orthogonal to the GC. In particular will the 5.4 GC work correctly if
> the UpValue model was left as is in 5.3?

The changes themselves are certainly not orthogonal, as the
implementation of the GC is intimately connected to the implementation
of the data graph. In a more abstract level, I don't know.  In
particular, the management of upvalues is somewhat complex, due to the
fact that stacks do not have write barriers, so Lua can change the
values of open upvalues behind their backs.

However, the upvalue model was changed after the new GC, so there
was a time when Lua (internally) had generational GC with the
old upvalue model. I don't remember exactly why we changed. The
comment says only "simpler and better for generational mode"
(see commit a3d36fe2).

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding back-porting Lua 5.4 GC to 5.3

Dibyendu Majumdar
On Mon, 22 Jun 2020 at 14:39, Roberto Ierusalimschy
<[hidden email]> wrote:
>
> > I am trying to understand whether to backport the 5.4 GC to 5.3 one
> > would need some of the other changes that were made or are these
> > orthogonal to the GC. In particular will the 5.4 GC work correctly if
> > the UpValue model was left as is in 5.3?
>
> The changes themselves are certainly not orthogonal, as the
> implementation of the GC is intimately connected to the implementation
> of the data graph.

Of course the GC must be aware of the changes in the data graph, but
the opposite  is not true? I mean that the user of the GC (in this
case Lua implementation) simply needs to invoke write barriers
appropriately - i.e. there is no difference in how write barriers are
invoked between say the incremental GC and the generational GC I
assume.

> In a more abstract level, I don't know.  In
> particular, the management of upvalues is somewhat complex, due to the
> fact that stacks do not have write barriers, so Lua can change the
> values of open upvalues behind their backs.
>
> However, the upvalue model was changed after the new GC, so there
> was a time when Lua (internally) had generational GC with the
> old upvalue model. I don't remember exactly why we changed. The
> comment says only "simpler and better for generational mode"
> (see commit a3d36fe2).
>

I see. I was wondering if the upvalue change was somehow necessitated
by the generational GC changes, or it was simply for conceptual
clarity. I have previously looked at the commit you mention and my
previous attempt included the upvalue changes, but I wanted to keep
the ref counted upvalues for my current attempt to backport the new
GC.

Thanks and Regards
Dibyendu