Ask yourself why these closure objects exist:
this is because functions may be recursive (and not
necessarily by trailing calls), so the variables in
closures may refer not to the immediate parent
caller frame but to some ancestor frame at arbitrary
number of levels in the calls stack). To avoid every
access to the closure varaible to pass through a
chain, there's a need for a mapping which is created
and initialized before each call to rebind each
variable for the next inner call (according to the
closure's prototype): such object is allocated only
if there are external variables used by the function
that are not local to the function itself, they are
not directly within the stack window.
This explains also because the bytecode needs
separate opcodes for accessing registers and
upvalues: if they could be directly on the stack,
it would be enough to reference upvalues with
negative register indexes and then use the stack
as a sliding window, like we do in C/C++ call
conventions (except that stack indexes in C/C++
are negative for parameters, and positive for
local variables, some of the former being cached
in actual registers, but still supported by
"shadow" variables on the stack, allocated at
fixed positions in the stack fram by the compiler
or just pushed before the actual parameters and
popped to restore these registers after the call).
There's been performance tests that show that
closures are not so fast, they can create massive
amounts of garbage collected objects (with
internal type LUA_TCLOSURE). I think this behavior
very curious, and the current implementation that
allocates the LUA_TCLOSURE objects on the heap is
not the best option, the mapping could be
allocated directly in the stack of local
variables/registers of the caller (and all these
closure objects used by the caller could be merged
to a single one, i.e. as the largest closure
object needed for inner calls, merged like in an
union. The closure objects themselves to not hold
any variable value, these are just simple mappings
from a small fixed integer sets (between 1 and the
number of upvalues of the called function) and
variable integers (absolute indexes in the
thread's stack where the actual variable is
located).
The byte code is not as optimized as it could
be: the register numbers are only positive, the
upvalue numbers are also only positive, they could
forml a single set (positive integers for local
registers, negative integers for upvalues, meaning
that they are used to index the entries in the
closure object to get access to the actual
varaible located anywhere on the stack, outside of
the immediate parent frame). The generated
bytecode is not as optimal as it could be because
various operations can only work on registers or
constants (like ADD r1,r2,r3) so temporary
registers must be allocated by the compiler (let's
remember that the number of registers is limited).
As well Lua's default engine treat all registers
the same, when most of them will work with a
single r0 register (an "accumulator") which could
be implicit for most instructions, and this would
reduce the instruction sizes (currently 32-bit or
64 bits), which is inefficient as it uses too much
the CPU L1 data cache.
I'm convinced that the current approach in the
existing Lua VM engine and its internal
instruction set can be largely improved for better
performance, without really changing the language
itself, to get better data locality (smaller
instruction sizes, less wasted unused bit fields),
and elimination of uses of the heap for closures
(to dramatically reduce the stress on the garbage
collector)
