two questions about gc

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

two questions about gc

fatfatson
hi,all:
   there're 2 new questions confusing me:
   1.what's the difference between luaC_barrierf and luaC_barrierback? i know both of them are used to keep the invariant, but why are there 2 functions?
   2.in both of them, there is an assert "lua_assert(g->gcstate != GCSfinalize && g->gcstate != GCSpause);",   i know the GCPause statu is unbreakable, but it's not true for GCSfinalize, so why we can assert it here?
 
   thanks very much~~
Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

Roberto Ierusalimschy
>   1.what's the difference between luaC_barrierf and luaC_barrierback? i
> know both of them are used to keep the invariant, but why are there 2
> functions?

If you are assigning a white object to a black one, there are two ways
to restore the invariant: turn the white object into a gray one (so
move "forward" the gray line), or turn the black object into a gray one
(moving the gray line "back"). Based on some performance considerations,
we think that for some kinds of assignment it is better to mover forward
the barrier, while for others it is better to move it back.


>   2.in both of them, there is an assert "lua_assert(g->gcstate !=
> GCSfinalize && g->gcstate != GCSpause);",   i know the GCPause statu is
> unbreakable, but it's not true for GCSfinalize, so why we can assert it
> here?

During the GCSfinalize phase, we have already sweeped all objects, so
no object should be black (and therefore these functions should not
be trigered).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

fatfatson
If you are assigning a white object to a black one, there are two ways
to restore the invariant: turn the white object into a gray one (so
move "forward" the gray line), or turn the black object into a gray one
(moving the gray line "back"). Based on some performance considerations,
we think that for some kinds of assignment it is better to mover forward
the barrier, while for others it is better to move it back.
 
thank you for your answer very much! but i'm still missing for the first question.
i found luaC_barrierback is only used when the black object is a table,  while luaC_barrierf is for the other type.
why can't we simply mark the white object to grey as what luaC_barrierf do? if we turn the parent table back to grey, it means all of its son objects will be traversed again, what's the reason we have to do this? is there any special characters of  table type?
 

 
Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

Roberto Ierusalimschy
> thank you for your answer very much! but i'm still missing for the first
> question.
> i found luaC_barrierback is only used when the black object is a table,
> while luaC_barrierf is for the other type.
> why can't we simply mark the white object to grey as what luaC_barrierf do?
> if we turn the parent table back to grey, it means all of its son objects
> will be traversed again, what's the reason we have to do this? is there any
> special characters of  table type?

As I said, we could mark the white object to gray. It is just a matter
of (expected) performance.

When you assign to a table, there is a good chance that you will assign
many other values to that same table. If we use barrierf here, all
these objects will be marked: that means a call to barrier for each
assignment, and also means that none of these objects will be collected
in this cycle. By changing the table back to gray, the following
assignments do not trigger the barrier (so they become faster) and the
assigned objects may still be collected in that cycle (if they are
overwritten before the table is traversed again).

(All this is highly speculative, of course. It depends on the program
behavior. Currently we have no strong results to support this option.
Actually, we do not have a good set of programs to test the behavior
of the garbage collection in "real" situations. It would be very
useful to have such a set.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

fatfatson
(All this is highly speculative, of course. It depends on the program
behavior. Currently we have no strong results to support this option.
Actually, we do not have a good set of programs to test the behavior
of the garbage collection in "real" situations. It would be very
useful to have such a set.)
 
ok,i think i've understood fully,thanks a lot :-)
by the way,as my own opinion, i thought that the table type is the only container type who is interactable to programmers, so it may faces more situations than any other ones(such as proto,clousure), and luaC_barrierback seems "safer" than luaC_barrierf .
Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

Roberto Ierusalimschy
> ok,i think i've understood fully,thanks a lot :-)
> by the way,as my own opinion, i thought that the table type is the
> only container type who is interactable to programmers, so it may faces more
> situations than any other ones(such as proto,clousure), and luaC_barrierback
> seems "safer" than luaC_barrierf .

What do you mean by "safer"?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: two questions about gc

fatfatson
What do you mean by "safer"?
 

It means ... before I read your intro about why to use luaC_barrierback/luaC_barrierf, I think table type is the only container type that Lua programmer can operate with, so lua vm won't know how the table will be used by programer. And just using luaC_barrierback to make the parent object gray is better, as all values in the table will be re-traversed by gc again. But using luaC_barrierf, maybe, make something lost(won't be collected) in the gc cycle.

Well, as I don't think my opinion is right, I wrote this mail and ask :-) ...