Lua5.3 GC源码阅读(1)

最近Lua 5.4 work1已经发布了, 其中GC最大的变化就是增加了分代GC的实现, 而GC在动态语言中一向是重中之重. 趁着这个机会, 我打算具体比较一下Lua5.3和Lua5.4中GC实现到底是如何变迁的, 根据以往的经验来看, 这其中必然充满各种精巧的设计. Lua5.3的GC源码以前就断断续续看过一次了, 这次打算从头再分析一遍, 并做一下笔记为分析Lua5.4 GC做准备. 在Lua中字符串、表、用户数据、函数、线程、 内部结构等对象，都使用GC模块进行管理. 在分析GC流程前先做一些准备工作, 比如lua中的Val……

三角形光栅化时遇到的坑

前一段时间打算写一个完整的游戏, 客户采用Unity3D引擎, 服务端则采用我自己的Silly网络框架。 然而，最终这个项目烂尾了。烂尾的原因有很多，比如缺少资源，在不断寻找资源过程中使自己开发的热情消失殆尽等。但更为重要的是，我发现在使用Unity3D过程中，除了拼接UI逻辑时，没有碰到太大困难外。在实现一些3D效果时竟处处掣肘，甚至连最简单的贴花系统都实现不了。 而此时我的图形学背景是，《3D数学基础：图形与游戏开发》，《DirectX9.9 3D游戏开发编程基础》，《Unity Shader入……

一次git事故

在开发过程中，我们的版本管理方式是，一版本一分支。之所以这样，是因为随着开发的进行，版本随时会分叉（这里分叉是指，两个版本都需要后续开发，但是对同一模块的功能需要不一样的微调)。 随着分叉之后的持续开发，就会导致多个分支之间差别越来越大。因此，如果所有版本都添加同样功能或修改同一个Bug时，是不可以采用git merge的方式来进行的。因为很难找到他相同的父节点。这时patch会是一个很好的工具。 而这次事故正是git patch功能使用不当引起的，下面来模拟出一个完整的……

再见2017

2017年过的格外的快，似乎2016年元旦刚过去没多久，2017年的元旦又来了。 大致回溯了一下2017，好像什么也想不起来了。只好重新扒了一下Blog，才慢慢回想起这一年到底干了些什么。 仿佛是为了印证“计划赶不上变化”这句话。2016年定下的目标，依然没有全部完成。这几乎是一个惯例，每年初定下的目标，到了第二年去看时，一定没有100%完成。而我也已经习惯了这个规律。 2016年目标进度如下： luaVM的源码并没有读完，只是其中断断续续的读了一部分。到目前为止，已读代码包括：string……

又一个lua调试器

最初，我并没有打算为Silly提供一个lua调试器，因为我本人不是一个重度调试器使用者。在开发期间出bug，看一下代码，打几条log可能比使用调试器会更快的找到问题，尤其是服务端程序，在很多时候其实只有log这一原始工具可以使用。但就我周围的人来推断，应该还是有很多重度调试器使用者。 因此，最终还是计划为Silly增加一个lua调试器作为基本组件存在。但是这个调试器到底以哪种方式提供调试功能，我一直在纠结中。 就我个人而言，我用过至少两种完全不同的调试器，gdb和dtrace（严……

客户端缓存落地方案

先大致描述一下场景，客户端按登陆流程成功登陆后，开始按各个模块加载所需数据，待收到消息返回后cache在内存中，只有当所有模块全部加载完成之后，客户端才算真正登陆成功，这时玩家才可以进行各种操作。在玩家操作过程中，客户端不断与服务器进行消息交互，并始终与服务器数据保持一致（这里是指状态一致，不是指所有数据全部一致，服务端存储的数据与客户端所需要的数据并不完全相同）。 由于模块过多，每个模块都是分别独立加载，因此从用户点击登陆按钮开始到真正可以操作所经……

Paxos算法

大神说，世界上只有一种一致性算法，那就是Paxos。 但是大部分文章或论文的套路都差不多，先说paxos是一个完美的一致性算法，然后就给出证明等等，最后才给出实现步骤。 然而，对于我这个初学者来讲，我更希望先知道这个算法是如何工作的，然后再去研究他们的证明过程。这其实也符合学习的过程，先抛出问题，思考之后，最后看答案印证。然而大神写的Chubby并不开源，而证明过程也很数学化，很难理解在实际执行流程当某一步出现错误时，这个算法是如何保证数据的一致性的。 本文从pax……

HTTP服务器的特点

最近一个月在学习关系性数据库mysql, 顺便看了一下http服务器的编写。写了这么久的游戏服务器,数据库也一直使用nosql。因此在初次尝试使用mysql编写http服务器程序时，产生了强烈的反差。 在使用APP的验证过程中，经常会遇到短信验证码问题。 下面就以‘如何实现短信验证码服务’来对比一下http服务器和游戏服务器（mysql和nosql)解决此类问题的不同之处。主要涉及数据结构定义、优化、及逻辑代码的更新问题。 先来明确一下‘业务流程’，最简单的‘短信验证码服务’至少要提供3个操……

一次性能优化经历

自从上次修改backlog之后, Silly的IO能力，就一直以少量（约4~6K)的差距落后于redis，却一直找不到原因。 这次打算从头做一次profile来问题到底出在哪。 先用GNU提供的gprof分析一下C代码是否有值得优化的地方，结果发现CPU使用率最高的地方是luaVM内部和malloc/free。 我们所有的业务逻辑全在lua层做的，而IO线程与worker(lua)线程进行交互时是通过malloc来实现的。这几乎表明C代码几乎已经没有优化的余地了。 但是有个好消息，就是gprof不去profile系统调用和so，也许还有机会。 ……

关于CPU分支预测

由于很偶然的原因，这两天瞄了几眼”ZeroMQ”项目，发现项目中使用了’likely/unlikely’这种暗示编译器做分支预测优化的宏（这些宏只是gcc内建函数__builtin_expect的别名)。 其实早在看linux kernel源码时，就不止一次看到这组宏。但是，对此并没有放在心上。仅仅粗略搜了一下，得知‘likely/unlikely这组宏可以向编译器提供分支预测信息，以便编译器可以更好的安排指令顺序来提高效率’就没有再深入下去了。 因为我觉得，这种级别的优化估计能提高个千分之几就……

更多