Lua performs automatic memory management.
This means that
you have to worry neither about allocating memory for new objects
nor about freeing it when the objects are no longer needed.
Lua manages memory automatically by running
a garbage collector from time to time
to collect all dead objects
(that is, objects that are no longer accessible from Lua).
All memory used by Lua is subject to automatic management:
tables, userdata, functions, threads, strings, etc.
Lua implements an incremental mark-and-sweep collector.
It uses two numbers to control its garbage-collection cycles:
the garbage-collector pause and
the garbage-collector step multiplier.
Both use percentage points as units
(so that a value of 100 means an internal value of 1).
The garbage-collector pause
controls how long the collector waits before starting a new cycle.
Larger values make the collector less aggressive.
Values smaller than 100 mean the collector will not wait to
start a new cycle.
A value of 200 means that the collector waits for the total memory in use
to double before starting a new cycle.
The step multiplier
controls the relative speed of the collector relative to
memory allocation.
Larger values make the collector more aggressive but also increase
the size of each incremental step.
Values smaller than 100 make the collector too slow and
can result in the collector never finishing a cycle.
The default, 200, means that the collector runs at "twice"
the speed of memory allocation.
You can change these numbers by calling lua_gc in C
or collectgarbage in Lua.
With these functions you can also control
the collector directly (e.g., stop and restart it).
Using the C API,
you can set garbage-collector metamethods for userdata (see §2.8).
These metamethods are also called finalizers.
Finalizers allow you to coordinate Lua's garbage collection
with external resource management
(such as closing files, network or database connections,
or freeing your own memory).
Garbage userdata with a field __gc in their metatables are not
collected immediately by the garbage collector.
Instead, Lua puts them in a list.
After the collection,
Lua does the equivalent of the following function
for each userdata in that list:
function gc_event (udata)
local h = metatable(udata).__gc
if h then
h(udata)
end
end
At the end of each garbage-collection cycle,
the finalizers for userdata are called in reverse
order of their creation,
among those collected in that cycle.
That is, the first finalizer to be called is the one associated
with the userdata created last in the program.
The userdata itself is freed only in the next garbage-collection cycle.
A weak table is a table whose elements are
weak references.
A weak reference is ignored by the garbage collector.
In other words,
if the only references to an object are weak references,
then the garbage collector will collect this object.
A weak table can have weak keys, weak values, or both.
A table with weak keys allows the collection of its keys,
but prevents the collection of its values.
A table with both weak keys and weak values allows the collection of
both keys and values.
In any case, if either the key or the value is collected,
the whole pair is removed from the table.
The weakness of a table is controlled by the
__mode field of its metatable.
If the __mode field is a string containing the character 'k ',
the keys in the table are weak.
If __mode contains 'v ',
the values in the table are weak.
After you use a table as a metatable,
you should not change the value of its __mode field.
Otherwise, the weak behavior of the tables controlled by this
metatable is undefined. |