Lua GC 的源码剖析 (3)
有了前几天的基础,我们可以从顶向下来读 lua gc 部分的代码了。
我们知道,lua 对外的 API 中,一切个 gc 打交道的都通过 lua_gc
。C 语言构建系统时,一般不讲设计模式。但模式还是存在的。若要按《设计模式》中的分类,这应该归于 Facade 模式。代码在 lapi.c 的 895 行:
有了前几天的基础,我们可以从顶向下来读 lua gc 部分的代码了。
我们知道,lua 对外的 API 中,一切个 gc 打交道的都通过 lua_gc
。C 语言构建系统时,一般不讲设计模式。但模式还是存在的。若要按《设计模式》中的分类,这应该归于 Facade 模式。代码在 lapi.c 的 895 行:
早期的 Lua GC 采用的是 stop the world 的实现。一旦发生 gc 就需要等待整个 gc 流程走完。如果你用 lua 处理较少量数据,或是数据增删不频繁,这样做不是问题。但当处理的数据量变大时,对于实时性要求较高的应用,比如网络游戏服务器,这个代价则是不可忽略的。lua 本身是个很精简的系统,但不代表处理的数据量也一定很小。
最近发现在大数据量的 lua 环境中,GC 占据了很多的 CPU 。差不多是整个 CPU 时间的 20% 左右。希望着手改进。这样,必须先对 lua 的 gc 算法极其实现有一个详尽的理解。我之前读过 lua 的源代码,由于 lua 源码版本变迁,这个工作还需要再做一次。这次我重新阅读了 lua 5.1.4 的源代码。从今天起,做一个笔记,详细分析一下 lua 的 gc 是如何实现的。阅读代码整整花掉了我一天时间。但写出来恐怕比阅读时间更长。我会分几天写在 blog 上。
本章,我将深入探讨lua的upvalue机制。在写这篇博客之前,我已经自己动手实现了这个机制,并且将其提交到了github仓库dummylua上了。为了专注于upvalue机制本身的讨论,本章不会展示大量的代码细节,尽量在抽象层面来论述。
本章节,我开始对dummylua的userdata的设计与实现,进行论述。它的大体设计与实现,仍然是仿照了lua5.3的标准,由于,所有的内容,都是我自己理解后,重新实现,因此在一些实现细节上略有不同,但是整体设计思路遵循了lua的设计思想。本章的篇幅不会很长,因为userdata这个部分并不是非常复杂,因此我这里也会速战速决,将userdata的一些核心思想论述清楚,就将本章完结。
userdata是用来存放,用户自定义的数据结构实例的,userdata的种类有两种,一种是lightuserdata,还有一种则是full userdata。light userdata是Value结构中的一个变量类型,本质是一个void* 指针
Posted on December 8, 2020
本章,我们将进入到metatable的探索之中。由于这块本身比较简单,而且我也不打算罗列代码细节,因此本章的篇幅不会很大。只是对一些我认为比较关键的部分,进行说明。首先,本章的主要任务,首先是简要介绍metatable是做什么的,然后简要说明一下,它如何被设置,接着介绍metatable的访问域,双目运算操作域、单目运算操作域等。最后会告诉读者,本章的实现逻辑位于dummylua工程的哪些部位。
前面,我已经用3篇blog的巨大篇幅,详细论述了Lua编译模块的一些基本知识。其中,Part5通过一个简单的打印hello world的例子,论述了编译出来的虚拟机指令,如何存到Proto结构中,最后再通过虚拟机执行的流程。Part6详细论述了,词法分析器的设计与实现。而Part7则论述了,expression的编译流程。本章,将作为Lua内置编译器论述的最后一个部分。往后的部分,将不再涉及编译相关的内容。当然,经历这篇,相信读者能够完全理解Lua内置编译器的设计与实现,个人认为完整度还是比较高的。
在上一章里,我完成了词法分析器的设计与实现的论述,接下来我要继续论述语法分析器的设计与实现。限于篇幅,我将会把语法分析器分为两个部分来论述,本章为上部,下一章为下部。本章将会重新复习编译器的构造,并且论述编译流程,以及lua的parser所涉及的编译相关的内容,最后通过阐述虚拟机相关指令的实现,作为结尾。本章所涉及的代码,全部在dummylua工程里,欢迎star。另外,如果你喜欢我写的文章,喜欢讨论技术,欢迎加入我创建的群:QQ185017593