 |
lua-l archive |
|
|
||
|
|
> The reason is very subtle. (It took me some time to remember ;)
> > Lua uses a register-based virtual machine. One problem with these > machines is how the GC knows which registers are valid and which > registers are garbage. Lua solves this problem thanks to its naive > register-allocation policy. Registers are allocated in a stack-based > way; so, if Lua knows the last allocated register, it knows that all > registers up to that point are valid, all others after that are garbage. > > But how does Lua know the last allocated register? All instructions > that can invoke the GC (OP_CLOSURE, OP_NEWTABLE, OP_CONCAT) code that > information in some way. Both OP_CLOSURE and OP_NEWTABLE put their > result in a new, fresh register, which therefore is the last one in use > when the instruction runs. > > (OP_CONCAT is a little different. Because its arguments must be > in sequential registers, they are already using the top of the > stack. So the last register is either the result register or > the argument register, whichever is larger.) > > -- Roberto > Hi Roberto Thanks for the reply. According to your answer I reviewed the relevant code in lgc.c and lvm.c. "traversestack" will mark all gcobject on the stack until top. Every instruction that will create gcobject will do a checkGC on the end. "checkGC" will set stack top to instruction register and do a gc step. This may bring the "compile time infomation" which indicate the current "top" to the runtime. But what is the purpose of doing this? This may be helpful to mark object precisely when using a "stop world" gc. But when using "incremental gc", it seems useless. -- Yuanlin |