近很少上来知乎冒泡。倒不是有意要远离知乎，只是工作忙生活忙心情起伏外加若干程度地沉迷游戏所以近没动力码字。看到有不少未回复的评论、私信和催稿…抱歉近几乎全部都没能响应。（近期有收到我回复的大大和同学们，你们是少数…）实在是抱歉哈。
上面的亮点肯定是沉迷游戏。预防性写一句：近没在工作也没在处理生活事件的时候，有不少时间都在玩手游。名字是「歌マクロス」。这么多年了Macross这么好的IP一直没出otoge，这一出我实在是招架不住啊。然而我还是努力保持在了无课金状态（哈哈哈
有一起玩的同学不…？
（之前的Gundam Conquest、LoveLive、CGSS都暂时扔下了。邦邦星人还没开打）
其实没在工作的时间就已经很少了。剩下的时间几乎都是在处理生活事件（全靠岳父岳母在这边帮忙，不然我就不是这种“感到紧张”的状态了，大概得是“明天还能活着么”了orz）。能有个喜欢的游戏转移一下注意力真是救赎。现在我每天上下班在路上总共几乎要消耗掉4个小时，单程～2小时 = 走路去火车站～10分钟 + 火车～75分钟 + 走路去办公室～30分钟。走路的时候啥其它事情也做不了，火车上如果运气好能有位子坐的话…就是回邮件、读论文和间歇性打打歌マクロス了。
其实有好些话题上我很想码点新的文字。
SQL语言
4月份开始刚入职Databricks之后，我在 @连城 大大的指导下重新学习了一下SQL语言，以前没用过的having、window function、CTE之类的语言层面功能都新学习了一把。然后为了练手顺便刷了些知乎上的很老的SQL入门问题…污染了关注了我的大大们的timeline真是不好意思。
除了入门级练手题之外，本来也想在一些讨论SQL语言自身的问题下码点字。但一来自己对SQL语言的熟悉程度仍然不足，真要写也写不出什么真知灼见；二来想写点有用的东西还挺烧时间，就还没动手写。（找借口#1
Spark
同上，在来到新公司之前，我对Spark以及其它大数据处理框架几乎是一无所知。其实我还在淘宝工作的时候就听说过Spark的名字。我们在核心系统部的时候旁边正好有霸爷的MySQL组、阳老师的OceanBase组，还有Hive / Hadoop组…惭愧的是当时那么好的资源，我可以说是完全没能从身边几个组的大大吸收到他们的领域知识，而现在我工作正好就需要用上这些方面的知识了。当时我就知道Spark是个新东西，可以替代Hadoop MapReduce，而且因为可以做内存计算所以更快。然后除此之外就什么都不知道了。
那个时候ZHH-2009大大也还在淘宝，他教导我说要把视野放开一点，除了JVM与编译器之外，其它方面也要多深入学习和动手实现一下，例如说从下向上：操作系统、数据库、Java中间件、Web服务器、Web开发框架之类的东西都多涉猎一点的好。现在我痛感当时应该听他的建议多向身边的大大学习各种不同的特定领域知识的。
来到美国在Azul Systems工作的时候，有一次机会去过Databricks早期还在Berkeley的办公室转过一圈，那个时候听带我过去的大大介绍说Spark是一个基于DAG调度的、可以在内存里做分布式计算的、泛化的MapReduce系框架。嗯。然而这几个修饰词对当时的我来说可以说是完全…“你在说啥？”。
DAG这个抽象概念我当时每天工作也天天见，但是放在MapReduce的上下文里是指什么东西构成的图是DAG？在内存里的计算相对于要做磁盘I/O的计算也好理解，但是放在分布式计算的上下文里是什么意思？这整个东西跟MapReduce有什么关系？MapReduce系的分布式计算系统自身又跟我还算熟悉的函数式语言中的map() + reduce() 或 fold() 是什么关系？——这些问题我都不知道答案，完全是一头雾水。
后来在Azul Systems的工作中也“遭遇”过Spark。我们的老版本的Zing VM在某些老版本的Spark上，跑某些benchmark相比HotSpot VM会慢不少。为了争取客户，这性能问题当然得想办法调查清楚然后在VM里面解决。于是我跟同事一起不断跑Spark 1.4.x + TPC-DS测试，调查性能差异的来源然后实现新优化来改进Zing VM的性能。当时是做了不少有趣的东西，也看到了Spark 1.4跑TPC-DS的若干query的性能profile。但是我们当时完全没关心上面Spark到底在干什么，全部都是在bytecode层面开始往下去分析，真要说对Spark有多少了解，那是完全说不上的。而且有趣的是我们针对老版本的Spark的性能问题在Zing里做的改进还挺通用，对若干其它应用也带来了一定性能提升，然而比较新版本的Spark通过codegen把那些坑给填了…
又到大家肯定要八卦的地方了：Spark 1.4里哪里踩到JVM的坑了？其实有好一些…这里就说一个。如果有代码是这样的形式的：要对一个可能有很多行的数据做操作，其中每一列（每个字段）有自己的操作，而这些操作都先根据元数据生成出lambda（例如scala.Function1）来实现，然后遍历每行数据的时候对每列都调用对应的lambda…会非常非常慢。这种代码里对lambda表达式的调用的地方常常会是高度多态（highly polymorphic或者说megamorphic）的，JVM很难对其有效做去虚化（devirtualize）的优化，而不去虚化就难以内联，不内联很多进一步的优化都做不了，就会特别特别特别慢。可能跑某些benchmark的时候，正好在这种位置上某些JVM实现碰巧能通过profile-guided optimization做了动态去虚化而另一些JVM碰巧每做，性能就有很大差异了；但一般来说这种代码形无论在什么JVM上都无法得到靠谱的优化的，某个benchmark上某段代码碰巧得到某个JVM的优化不代表一般的workload在同一段代码+同一个JVM上都能得到同等程度的优化。
来到Databricks之后，工作需要和个人技术兴趣都驱动我好好学习Spark。半年下来，抱着 @连城 大大和许多其他大大，例如 @朱诗雄 大大等的大腿，好歹算是学到了点皮毛。其中我还是对Catalyst的部分了解得稍微深一些，而对其它部分还停留在一知半解的状态。
所以看到Catalyst相关的问题的时候其实会手很痒想码点字的。特别是像这个问题：Spark Catalyst源码该从何读起？ <- 好吧这种问题很大而问题描述什么都没有的，一般是让人比较头疼，但话题上说还是让我手很痒想去写回答。等我慢慢码字吧…
数据库系统
在学习Spark SQL的过程中，我很快就撞上了一堵墙：Spark SQL里很大一部分东西都是跟传统关系型数据库系统的query optimizer / query planner是一脉相承的。然而我从来没有关注过数据库是如何实现的，这块知识完全是个空白。
要理解Spark SQL特别是其中的Catalyst优化器部分的实现，不恶补一下数据库实现的各种基础知识会很难深入下去。那就学呗。越学就越觉得这方面真是有趣得很，只恨自己以前没早点对它产生兴趣。回过头来看，Catalyst其实算是个比较简单的优化器，而且至少一开始还算是比较简洁的。
在数据库方面的学习笔记，我也想有机会的话码点字记录一下。要写主要也还是在前端部分，至于存储层、事务管理这些很核心的部分我都还没能真正入门，还有待继续学习啊。
OMR / OpenJ9
近的大事情之一就是：IBM的OpenJ9的源码终于开放出来了！这么重大的新闻我怎能不跟进。然而还没空码字…
Java 9
同样，Java 9也正式发布了！这么重大的进展我怎能不跟进…不过这方面我码字的优先级可能会很低，看上面都那么多想码的字了…
JVM Language Summit 2017（JVMLS）
今年是我次以不是JVM开发者的身份去参加JVMLS，自己觉得心境变化还挺好玩。要是有空的话也想码点字写写见闻的…
还有其它
近觉得好玩的、值得码字的东西还有好多好多好多…天呐 ToT
像是CoreCLR / RyuJIT里也有许多想记录的新东西。Weld、Truffle / Graal、V8 TurboFan / Ignition等也想写点好玩的。
时间精力有限，只能挑点小方面来码字了（呜呜
