Joe Armstrong 在愚人节介绍了too_big_to_fail flag,这个东西真是好多疑问啊,希望只是愚人节的一个玩笑.

Too_big_to_fail_process进程平时和正常进程一样,一旦需要更多内存的时候面目就开始狰狞起来:如果它需要内存的时候出现了分配内存错误,就会随机挑选比较占用资源比较少的进程杀掉,然后重新尝试为too_big_fail进程分配内存.

如果是杀了本节点内其它所有进程还是不够用怎么办?会从其它节点"窃取"内存!!!! Too_big_to_fail_process 进程会在其它节点创建自己的副本,在该节点继续分配自己需要的内存.具体细节:

• too_big_to_fail_process 在节点A耗尽内存
• "helper"进程在节点B分配内存
• "helper"在其所在节点尽可能的分配内存
• too_big_to_fail_process减少在节点A的内存使用量,转而使用在节点B占用的内存
• 反复执行 如果这两个节点都内存耗尽就尝试从别的节点继续上面的"窃取"过程

如果所有的too_big_to_fail_nodes内存都被耗尽了,还有垂死一搏:"Memory Allacator of Last Resort".这个内存分配器还有能力分配新的内存,如果幸运点分配的速度比消耗的速度快,那就小车不倒继续推一直跑下去,如果内存消耗速度快于分配的速度,系统就会崩溃,需要重启.

too_big_to_fail_process 将跟随OTP-R18B发布,目前memory allocator of last resort的相关研究工作还在进行中.

我的疑问:

1. 什么样的业务场景需要设计这样霸气的进程?（怎么看都像一个玩笑）
2. 占用多个节点内存的情况,这个进程怎么协调内部逻辑的?
3. Memory Allacator of Last Resort 是做数据压缩来争取内存空间么?(GC还有机会么?)
4. 一个Vm里面有两个这样的进程,策略是怎样的?

请教了一下@淘宝褚霸 得到答复 ：

[0] http://site.douban.com/204209/

[1] http://joearms.github.com/2013/04/01/too-big-to-fail.html

[2] http://www.reddit.com/r/programming/comments/1bfqcz/joe_armstrong_too_big_too_fail_flag_for_erlang/

[3] http://developers.slashdot.org/story/13/04/01/2230220/erlang-getting-too-big-to-fail-process-flag

最后小图一张: