源码阅读顺序
Lua的源码短小精悍，一般的阅读顺序是建议从外围到内层。例如，下面这个顺序是reddit上的一篇帖子的推荐：
Recommended reading order
If you're done before X-Mas and understood all of it, you're good. The information density of the code is rather high.
-
lmathlib.c,lstrlib.c: get familiar with the external C API. Don't bother with the pattern matcher though. Just the easy functions. -
lapi.c: Check how the API is implemented internally. Only skim this to get a feeling for the code. Cross-reference to lua.h and luaconf.h as needed. -
lobject.h: tagged values and object representation. skim through this first. you'll want to keep a window with this file open all the time. -
lstate.h: state objects. ditto. -
lopcodes.h: bytecode instruction format and opcode definitions. easy. -
lvm.c: scroll down to luaV_execute, the main interpreter loop. see how all of the instructions are implemented. skip the details for now. reread later. -
ldo.c: calls, stacks, exceptions, coroutines. tough read. -
lstring.c: string interning. cute, huh? -
ltable.c: hash tables and arrays. tricky code. -
ltm.c: metamethod handling, reread all of lvm.c now. - You may want to reread
lapi.cnow. -
ldebug.c: surprise waiting for you. abstract interpretation is used to find object names for tracebacks. does bytecode verification, too. -
lparser.c,lcode.c: recursive descent parser, targetting a register-based VM. start from chunk() and work your way through. read the expression parser and the code generator parts last. -
lgc.c: incremental garbage collector. take your time. - Read all the other files as you see references to them. Don't let your stack get too deep though.
我并没有按这个顺序读。外围的API在使用Lua以及给Lua写扩展库的过程中，已经比较熟悉了，C 的 API 在我看来都是按需查文档的事情，所以lmath和lapi.h这两部分并需要特地去每个看。所以也是直接到lobject.h和lstate.h来的。
其实，从lobject和lstate出发，我觉的是很有道理的。因为：程序=算法+数据结构。所以我们要先从梳理数据结构开始，这也是为什么在前几篇里，我总是有意略掉某个模块的具体细节。等把数据结构的轮廓整体大致理清之后，再把每个部分的方法部分展开，就变成体力活。当然一个语言在发展演化过程中，肯定不是一开始就是这样的，我们这样的做法，好像这些结构的设计是“天然的”，“一开始就想的非常周全”似的，所以有时候会拼命为某个字段为什么需要，为什么在那个地方给找理由，但实际的开发过程可能是经过N个版本和补丁后才变成那样的。
到这篇，我们开始看global_State对象，不过我依然会只做到梳理下脉络，而不展开细节。
global_State
上一篇提到，在lua_State对象里有一个global_State，这个才是Lua 状态机的全局状态的存储的地方，所有的lua_State共享这个全局状态，由于Lua被设计为单线程的，所以global_State上的状态控制变的简单很多，完全不考虑多线程问题。
/*
** 'global state', shared by all threads of this state
*/
typedef struct global_State {
lua_Alloc frealloc; /* function to reallocate memory */
void *ud; /* auxiliary data to 'frealloc' */
lu_mem totalbytes; /* number of bytes currently allocated - GCdebt */
l_mem GCdebt; /* bytes allocated not yet compensated by the collector */
lu_mem GCmemtrav; /* memory traversed by the GC */
lu_mem GCestimate; /* an estimate of the non-garbage memory in use */
stringtable strt; /* hash table for strings */
TValue l_registry;
unsigned int seed; /* randomized seed for hashes */
lu_byte currentwhite;
lu_byte gcstate; /* state of garbage collector */
lu_byte gckind; /* kind of GC running */
lu_byte gcrunning; /* true if GC is running */
GCObject *allgc; /* list of all collectable objects */
GCObject **sweepgc; /* current position of sweep in list */
GCObject *finobj; /* list of collectable objects with finalizers */
GCObject *gray; /* list of gray objects */
GCObject *grayagain; /* list of objects to be traversed atomically */
GCObject *weak; /* list of tables with weak values */
GCObject *ephemeron; /* list of ephemeron tables (weak keys) */
GCObject *allweak; /* list of all-weak tables */
GCObject *tobefnz; /* list of userdata to be GC */
GCObject *fixedgc; /* list of objects not to be collected */
struct lua_State *twups; /* list of threads with open upvalues */
Mbuffer buff; /* temporary buffer for string concatenation */
unsigned int gcfinnum; /* number of finalizers to call in each GC step */
int gcpause; /* size of pause between successive GCs */
int gcstepmul; /* GC 'granularity' */
lua_CFunction panic; /* to be called in unprotected errors */
struct lua_State *mainthread;
const lua_Number *version; /* pointer to version number */
TString *memerrmsg; /* memory-error message */
TString *tmname[TM_N]; /* array with tag-method names */
struct Table *mt[LUA_NUMTAGS]; /* metatables for basic types */
} global_State;
这么多字段，即使加了一堆注释，看上去依然是不直观的。怎样算直观的呢？我觉的能比较清晰看出层级关系的代码比较直观，层级关系一般就是代表了一个对象是由哪些子模块构成的，这是符合人类的线性直觉的吧？姑且怎么做：
/*
** 'global state', shared by all threads of this state
*/
typedef struct global_State {
// Version
const lua_Number *version; /* pointer to version number */
// Hash
unsigned int seed; /* randomized seed for hashes */
// Registry
TValue l_registry;
// String table
stringtable strt; /* hash table for strings */
Mbuffer buff; /* temporary buffer for string concatenation */
// Meta table
TString *tmname[TM_N]; /* array with tag-method names */
struct Table *mt[LUA_NUMTAGS]; /* metatables for basic types */
// Thread list
struct lua_State *mainthread;
struct lua_State *twups; /* list of threads with open upvalues */
// Error Recover
lua_CFunction panic; /* to be called in unprotected errors */
// Memory Allocator
lua_Alloc frealloc; /* function to reallocate memory */
void *ud; /* auxiliary data to 'frealloc' */
// GC
lu_mem totalbytes; /* number of bytes currently allocated - GCdebt */
TString *memerrmsg; /* memory-error message */
l_mem GCdebt; /* bytes allocated not yet compensated by the collector */
lu_mem GCmemtrav; /* memory traversed by the GC */
lu_mem GCestimate; /* an estimate of the non-garbage memory in use */
lu_byte currentwhite;
lu_byte gcstate; /* state of garbage collector */
lu_byte gckind; /* kind of GC running */
lu_byte gcrunning; /* true if GC is running */
int gcpause; /* size of pause between successive GCs */
int gcstepmul; /* GC 'granularity' */
unsigned int gcfinnum; /* number of finalizers to call in each GC step */
GCObject *allgc; /* list of all collectable objects */
GCObject *finobj; /* list of collectable objects with finalizers */
GCObject *gray; /* list of gray objects */
GCObject *grayagain; /* list of objects to be traversed atomically */
GCObject *weak; /* list of tables with weak values */
GCObject *ephemeron; /* list of ephemeron tables (weak keys) */
GCObject *allweak; /* list of all-weak tables */
GCObject *tobefnz; /* list of userdata to be GC */
GCObject *fixedgc; /* list of objects not to be collected */
GCObject **sweepgc; /* current position of sweep in list */
} global_State;
分开后，看一下，后面一大票都是垃圾回收相关的。要是一个语言不用处理垃圾回收的话，代码应该会清爽非常多，从这点来看，也许可以整理一个不管垃圾回收版本的Lua源码来看:)。
现在，我们可以进一步把垃圾回收的部分拆开：
typedef struct lua_GCInfo{
lu_mem totalbytes; /* number of bytes currently allocated - GCdebt */
TString *memerrmsg; /* memory-error message */
l_mem GCdebt; /* bytes allocated not yet compensated by the collector */
lu_mem GCmemtrav; /* memory traversed by the GC */
lu_mem GCestimate; /* an estimate of the non-garbage memory in use */
lu_byte currentwhite;
lu_byte gcstate; /* state of garbage collector */
lu_byte gckind; /* kind of GC running */
lu_byte gcrunning; /* true if GC is running */
int gcpause; /* size of pause between successive GCs */
int gcstepmul; /* GC 'granularity' */
unsigned int gcfinnum; /* number of finalizers to call in each GC step */
GCObject *allgc; /* list of all collectable objects */
GCObject *finobj; /* list of collectable objects with finalizers */
GCObject *gray; /* list of gray objects */
GCObject *grayagain; /* list of objects to be traversed atomically */
GCObject *weak; /* list of tables with weak values */
GCObject *ephemeron; /* list of ephemeron tables (weak keys) */
GCObject *allweak; /* list of all-weak tables */
GCObject *tobefnz; /* list of userdata to be GC */
GCObject *fixedgc; /* list of objects not to be collected */
GCObject **sweepgc; /* current position of sweep in list */
}GCInfo;
从而，global_State就会变的清晰很多：
typedef struct global_State {
// Version
const lua_Number *version; /* pointer to version number */
// Hash
unsigned int seed; /* randomized seed for hashes */
// Global Registry
TValue l_registry;
// Global String table
stringtable strt; /* hash table for strings */
Mbuffer buff; /* temporary buffer for string concatenation */
// Global Meta table
TString *tmname[TM_N]; /* array with tag-method names */
struct Table *mt[LUA_NUMTAGS]; /* metatables for basic types */
// Global Thread list
struct lua_State *mainthread;
struct lua_State *twups; /* list of threads with open upvalues */
// Memory Allocator
lua_Alloc frealloc; /* function to reallocate memory */
void *ud; /* auxiliary data to 'frealloc' */
// GC Info
GCInfo *gcinfo;
// Error Recover
lua_CFunction panic; /* to be called in unprotected errors */
}
- registry:
- 注册表管理全局数据
- string
- stringtable: 全局字符串表，几乎每个语言都会对字符串做池化，作成immutable的，Lua的字符串分短字符串和长字符串
- buff: 在Lua解析(parse)源代码的过程中，以及字符串处理过程中需要的临时缓存
- meta table，其实无论什么语言，所有的魔法都可以归结为“查表”，例如面向对象里的虚函数表，所有的OOP机制都依赖于虚函数表。
- tmname: metatable的预定义方法名字数组，tm是tag method的缩写
- mt：每个基本类型一个metatable，注意table、userdata等则是每个实例一个metatable。metatable+tag method可以说是整个Lua最重要的Hook机制。
- thread，当然global_State需要持有所有的线程（协程）。
- mainthread: 主线程
- twups: 闭包了当前线程变量的其他线程列表
- memory
- frealloc: Lua的全局内存分配器，用户可以替换成自己的
- ud: 分配器的userdata
- gc
- 垃圾回收所需要的信息特别多，先不管，整个垃圾回收系统应该单独来分析。
- error handle
- panic: 全局错误处理响应点
其中，stringtable如下：
typedef struct stringtable {
TString **hash;
int nuse; /* number of elements */
int size;
} stringtable;
待续
这样我们初步把gloabl_State的轮廓搞清楚了。后面，按global_State的子模块，逐个分析。