OOPSLA 2022有什么值得关注的论文？

自问自答，引蛇出洞！

希望各种做编程语言运行时的朋友可以关注一下我的工作，Optimal Heap Limits for Reducing Browser Memory Use。

这论文在解决的问题很简单 - 当我们有一个带GC的编程语言runtime的时候，这个GC该什么时候进行垃圾回收？

一般来说，一个runtime会有一个heap limit（L），当程序消耗内存量达到limit后，则会进行垃圾回收，使得内存使用量下降到limit以下。假设程序自己的live set size（无法被GC清掉的，还在用着的内存）是S, 那一般来说，会设置成L = N * S，其中N是一个2之类的常数。这代表着，一个带GC的程序的最大内存使用量，应该是手动内存管理的内存使用量的两倍。

但，这其实并不合理！我们在paper里面对垃圾回收进行数学建模，然后寻找一个这个问题的最优解。我们最后发现，应该设置成L = S + N * Sqrt(S)，就是说 - S越大，我们对应于原先的算法，应该给的内存越小！

这时候，我们的算法在v8 javascript engine上可以比原先的GC快30%（同等内存），又或者同等时间下节省15%的内存。我们的算法也实现进了racket，也一样有很好的结果。

这对应着经济学的边际效用递减原理 - 对于一个用了很多内存的VM，我们再多给一些内存，并不会造成很大影响。但是对于一个只用了一点点内存的VM，再多给同样多的内存，会造成更显著的影响。做一个奇怪的例子，你v我50吃肯德基疯狂星期四，跟你v Bill Gate 50，是完全不一样的概念 - 人家不差你这50，但我差。KFC，很奇妙吧。

这个工作也可以用在其他地方，比如深度学习（笑什么笑！没跟你开玩笑！）。事实上，这个工作就是受到了Dynamic Tensor Rematerialization的启发。在这个工作，为了节省内存，我提出了可以把整个GPU看成一个cache，然后每个独立的tensor都可能在cache里面（被计算出），或者不在cache里面（需要重计算）。我们用一个全局的cache policy决定什么tensor在cache中，什么tensor不在cache中。这个例子的insight是，当你有多个space time tradeoff的时候，需要一并考虑，才能得出pareto-optimal答案。

这个工作再进一步，指出了，在一定条件下，这个‘一并考虑’的过程并不需要任何信息的传递，可以每个子系统单独进行，但这依然可以达到全局最优。

那怕你不做垃圾回收，你也可以考虑考虑，你工作里面有没有接触什么很大挺占内存的cache。如果你有的话，就需要思考 - 这些cache各自做的space time tradeoff，真的consistent吗？该如何协调它们？