为什么最近仇富风气那么重？ 第7页

两天过去了，看的人，关注的人不少，能说得上话的看来是寥寥无几，除了青椒牛老板忆苦思甜了一下，七位靓号豹哥连回答的勇气都木有了，被吓跑了

那我先写一些目前已知的信息，权当是抛砖引玉

先说一下两个现有的低延时（low latency）的gc策略，zgc和shenandoah

zgc应该都很熟悉了，出来有一段时间了，这个是oracle官方团队做的，虽然说是官方团队，但其实是bea jrockit的人写的，以前sun的hotspot和bea的jrockit是早期比较出名的两个jvm实现，hotspot用c++实现，jrockit用c和java实现，说起来还挺好笑的，当时的评测结果是，hotspot更适合客户端，需要快速启动的程序，而jrockit更适合长期运行的程序^[1]，后来sun和bea都被oracle收购了，这两个jvm也就合二为一，其实更确切一点说就是，合并到hotspot中去，然后jrockit被贡献给了openjdk。然后jrockit的工程师per liden就是后来的zgc的team lead。zgc现在已经做到，大部分gc的latency在1ms以内，平均只有0.1 - 0.2ms之间，基本上无感知了，正常人条件反射的时间是0.25s，也就是250ms，经过训练的运动员，可以达到100ms，眼睛对于动画的感知，在1/60s左右，也就是17ms左右，经过训练的电竞之类的，可能可以达到90或者120fps，也就是8-9ms，就是人的极限了，现在gc最长导致程序的停顿在0.2ms以下，这种级别的停顿，人是不可能感知得到的

shenandoah是red hat的作品，现在red hat被ibm收购了，以前red hat和ibm，都有自己的jvm，分别是开源的iced tea和openj9，后者到现在还在不断出新，据说内存占用上会有一定优势，现在叫terium，北洋的下载网站^[2]上对terium和openj9的支持是很好的，更新得很积极。而iced tea在openjdk出来之后，基本上就处于被放弃的状态。那red hat后来基于openjdk，制作了自己的低延时的gc策略，就是shenandoah，shenandoah对比zgc，对硬件的要求相对低一点，但是对用户给出的承诺，也低一点，就像zgc早期，承诺在10ms以内完成全部gc，shenandoah从来没有给过任何这种承诺，也就是说，我尽力。然后官方oracle提供的openjdk的build里面，并不提供shenandoah，被oracle删了，但是其他的openjdk的build，都提供shenandoah这个gc策略，一般认为，zgc更适合客户端程序，shenandoah更适合服务器端程序，因为前者更满足一些硬性指标，比如保证10ms以内一定完成，后者就没有这个承诺，但是相对应的，前者对于资源的消耗也更大，一般要腾出15%左右的内存富余给zgc使用，然后cpu处理能力会有所下降，因为拿去给zgc用了，那相比之下，shenandoah对于这种资源的硬性要求就低，但是它同样也不给这个承诺，更像是随缘，我尽量，风险你自担

这是现有两个低延时gc

那按照新的gc的论文里面写的内容看，zgc和shenandoah虽然都实现了low latency，但是是以牺牲吞吐为代价，也就是需要一定的cpu和内存消耗，你需要为low latency腾出为了实现low latency gc的资源，相应的，等同cpu和内存的硬件的处理能力，就会相应下降一点，这其实也很合理，不能说既要马儿跑，又不让马儿吃草，让机器给你干点活，总要给人家点资源

但是，新的gc策略，简称lxr

认为，可以通过基于引用计数的策略，可以进一步降低对系统资源的占用，让gc在实现低延时的同时，又不需要牺牲太多cpu和内存资源，进而使得吞吐不受影响，所以论文的标题就是：低延时，高吞吐的gc策略

然后给出了一堆的评测结果，对于评测结果，你可能会怀疑，是吧，对比的openjdk 11的结果

但实际上，论文中有具体的validity，意思就是，他们打算把这个gc port到17上去，但是他们同时也对比了17的shenandoah，发现17的shenandoah和11的shenandoah结果几乎是一样的，而且11有backported improviement，也就是在后续版本中，shenandoah的改良，都会回溯到11的高版本中去，所以shenandoah的11没什么问题，17的zgc整体策略改变了，比较难对比，这个期待后续的比较吧

所以11没什么问题，然后期待他们给出17的build

然后说一下实现的过程，这个过程很有意思，他们先用rust开发了一个工具mmtk，然后这个工具提供了openjdk（c++写的）jikes rvm（java写的java研究虚拟机）和v8（c++写的）的绑定，然后再用这个rust写的绑定工具，实现了新的gc策略

从这一点上，可以看出，现在很多软件的研发，都已经从c++上转移到其他语言上去，这并不是坏事，因为c++的代码确实太难阅读了，openjdk的开发进度，其实受到c++语言本身混乱语法颇深，就是你可以感觉到，一大堆人做了好久（接近10年），但是进步相当有限，没什么成果，相比之下，你用其他语言，往往都能做得比c++更快，而且性能更好，就像graal的jit（用java aot实现的工具），什么都没改，直接替换openjdk里面的jit也就是c1/c2，都能在一些时候有高达15%的性能提升，所以现在这个时间点，没有什么太多理由继续沿用c++，当然openjdk本身的开发还要继续，只是源码这些，正在一点一点从c++中转移出去，那最终发展成什么样子，拭目以待了

然后这个gc本身诞生的环境，也很值得玩味

这是一个高校的论文，虽然三作是谷歌，但最重要的一作和二作，都是高校，这就预示了我之前说的，现在的科学和技术的发展，哪怕是技术这种科学的应用面，也越来越多，不再是企业能够推动得了的了，企业的目的是赚钱，但是推动科学技术的进步，更多的是一项事业，所谓事业，就是你要牺牲眼前短期利益，为了长远的发展考虑，那这个投入，都是动不动十年二十年的投入，企业没有那个耐心去等待，所以最好的方式就是，企业出钱，投资到高校等研究机构中去，这样一来可以减轻政府对高校的负担，人也更专业，高校里面教授博士一大堆，每天就是搞研究，企业里面，教授都罕见，教授也不愿意放弃铁饭碗去给你修福报，同时，因为是项目制的，所以搞完研究之后，一拍两散，企业不用负担教授博士们搞完研究离开公司（也就是裁员）的成本，所以这是多赢的局面，我国政府其实也正在推动这种校企合作，产学研嘛

然后这个就很好滴展示了，将来，对于技术的推动和进步，会是怎样的一种局面，除此之外，llvm，graal这些项目，研发主体也都在高校里面，现在是连传统openjdk的开发，也在逐步转移到高校中去，企业搞研究的时代，差不多过去了

所以你看，达摩院开始大面积裁员，湖畔大学关停，但是这些高校的研究成果，开始频频出现，以前关于gc的论文，还有不少是ibm，azul之类的企业发的，现在越来越多是高校发出来的，实际上虽然国内阿里用java的频次比较高，但是你看我写了这么多，有阿里什么事吗？

技术发展到一定阶段，就必然要求更高的研发门槛，就不是随便一个企业的打工仔，就能凭着一腔热血，搞搞搞，就能有所成就的，现在慢慢都过了那个阶段了，像国外贝尔实验室，早就不行了

最后本论文的一作好像是个华人

参考

1. ^ https://blog.dbi-services.com/a-comparison-of-java-virtual-machines-hotspot-jvm-vs-jrockit-jvm/
2. ^ https://www.injdk.cn/

两天过去了，看的人，关注的人不少，能说得上话的看来是寥寥无几，除了青椒牛老板忆苦思甜了一下，七位靓号豹哥连回答的勇气都木有了，被吓跑了

那我先写一些目前已知的信息，权当是抛砖引玉

先说一下两个现有的低延时（low latency）的gc策略，zgc和shenandoah

zgc应该都很熟悉了，出来有一段时间了，这个是oracle官方团队做的，虽然说是官方团队，但其实是bea jrockit的人写的，以前sun的hotspot和bea的jrockit是早期比较出名的两个jvm实现，hotspot用c++实现，jrockit用c和java实现，说起来还挺好笑的，当时的评测结果是，hotspot更适合客户端，需要快速启动的程序，而jrockit更适合长期运行的程序^[1]，后来sun和bea都被oracle收购了，这两个jvm也就合二为一，其实更确切一点说就是，合并到hotspot中去，然后jrockit被贡献给了openjdk。然后jrockit的工程师per liden就是后来的zgc的team lead。zgc现在已经做到，大部分gc的latency在1ms以内，平均只有0.1 - 0.2ms之间，基本上无感知了，正常人条件反射的时间是0.25s，也就是250ms，经过训练的运动员，可以达到100ms，眼睛对于动画的感知，在1/60s左右，也就是17ms左右，经过训练的电竞之类的，可能可以达到90或者120fps，也就是8-9ms，就是人的极限了，现在gc最长导致程序的停顿在0.2ms以下，这种级别的停顿，人是不可能感知得到的

shenandoah是red hat的作品，现在red hat被ibm收购了，以前red hat和ibm，都有自己的jvm，分别是开源的iced tea和openj9，后者到现在还在不断出新，据说内存占用上会有一定优势，现在叫terium，北洋的下载网站^[2]上对terium和openj9的支持是很好的，更新得很积极。而iced tea在openjdk出来之后，基本上就处于被放弃的状态。那red hat后来基于openjdk，制作了自己的低延时的gc策略，就是shenandoah，shenandoah对比zgc，对硬件的要求相对低一点，但是对用户给出的承诺，也低一点，就像zgc早期，承诺在10ms以内完成全部gc，shenandoah从来没有给过任何这种承诺，也就是说，我尽力。然后官方oracle提供的openjdk的build里面，并不提供shenandoah，被oracle删了，但是其他的openjdk的build，都提供shenandoah这个gc策略，一般认为，zgc更适合客户端程序，shenandoah更适合服务器端程序，因为前者更满足一些硬性指标，比如保证10ms以内一定完成，后者就没有这个承诺，但是相对应的，前者对于资源的消耗也更大，一般要腾出15%左右的内存富余给zgc使用，然后cpu处理能力会有所下降，因为拿去给zgc用了，那相比之下，shenandoah对于这种资源的硬性要求就低，但是它同样也不给这个承诺，更像是随缘，我尽量，风险你自担

这是现有两个低延时gc

那按照新的gc的论文里面写的内容看，zgc和shenandoah虽然都实现了low latency，但是是以牺牲吞吐为代价，也就是需要一定的cpu和内存消耗，你需要为low latency腾出为了实现low latency gc的资源，相应的，等同cpu和内存的硬件的处理能力，就会相应下降一点，这其实也很合理，不能说既要马儿跑，又不让马儿吃草，让机器给你干点活，总要给人家点资源

但是，新的gc策略，简称lxr

认为，可以通过基于引用计数的策略，可以进一步降低对系统资源的占用，让gc在实现低延时的同时，又不需要牺牲太多cpu和内存资源，进而使得吞吐不受影响，所以论文的标题就是：低延时，高吞吐的gc策略

然后给出了一堆的评测结果，对于评测结果，你可能会怀疑，是吧，对比的openjdk 11的结果

但实际上，论文中有具体的validity，意思就是，他们打算把这个gc port到17上去，但是他们同时也对比了17的shenandoah，发现17的shenandoah和11的shenandoah结果几乎是一样的，而且11有backported improviement，也就是在后续版本中，shenandoah的改良，都会回溯到11的高版本中去，所以shenandoah的11没什么问题，17的zgc整体策略改变了，比较难对比，这个期待后续的比较吧

所以11没什么问题，然后期待他们给出17的build

然后说一下实现的过程，这个过程很有意思，他们先用rust开发了一个工具mmtk，然后这个工具提供了openjdk（c++写的）jikes rvm（java写的java研究虚拟机）和v8（c++写的）的绑定，然后再用这个rust写的绑定工具，实现了新的gc策略

从这一点上，可以看出，现在很多软件的研发，都已经从c++上转移到其他语言上去，这并不是坏事，因为c++的代码确实太难阅读了，openjdk的开发进度，其实受到c++语言本身混乱语法颇深，就是你可以感觉到，一大堆人做了好久（接近10年），但是进步相当有限，没什么成果，相比之下，你用其他语言，往往都能做得比c++更快，而且性能更好，就像graal的jit（用java aot实现的工具），什么都没改，直接替换openjdk里面的jit也就是c1/c2，都能在一些时候有高达15%的性能提升，所以现在这个时间点，没有什么太多理由继续沿用c++，当然openjdk本身的开发还要继续，只是源码这些，正在一点一点从c++中转移出去，那最终发展成什么样子，拭目以待了

然后这个gc本身诞生的环境，也很值得玩味

这是一个高校的论文，虽然三作是谷歌，但最重要的一作和二作，都是高校，这就预示了我之前说的，现在的科学和技术的发展，哪怕是技术这种科学的应用面，也越来越多，不再是企业能够推动得了的了，企业的目的是赚钱，但是推动科学技术的进步，更多的是一项事业，所谓事业，就是你要牺牲眼前短期利益，为了长远的发展考虑，那这个投入，都是动不动十年二十年的投入，企业没有那个耐心去等待，所以最好的方式就是，企业出钱，投资到高校等研究机构中去，这样一来可以减轻政府对高校的负担，人也更专业，高校里面教授博士一大堆，每天就是搞研究，企业里面，教授都罕见，教授也不愿意放弃铁饭碗去给你修福报，同时，因为是项目制的，所以搞完研究之后，一拍两散，企业不用负担教授博士们搞完研究离开公司（也就是裁员）的成本，所以这是多赢的局面，我国政府其实也正在推动这种校企合作，产学研嘛

然后这个就很好滴展示了，将来，对于技术的推动和进步，会是怎样的一种局面，除此之外，llvm，graal这些项目，研发主体也都在高校里面，现在是连传统openjdk的开发，也在逐步转移到高校中去，企业搞研究的时代，差不多过去了

所以你看，达摩院开始大面积裁员，湖畔大学关停，但是这些高校的研究成果，开始频频出现，以前关于gc的论文，还有不少是ibm，azul之类的企业发的，现在越来越多是高校发出来的，实际上虽然国内阿里用java的频次比较高，但是你看我写了这么多，有阿里什么事吗？

技术发展到一定阶段，就必然要求更高的研发门槛，就不是随便一个企业的打工仔，就能凭着一腔热血，搞搞搞，就能有所成就的，现在慢慢都过了那个阶段了，像国外贝尔实验室，早就不行了

最后本论文的一作好像是个华人

参考

1. ^ https://blog.dbi-services.com/a-comparison-of-java-virtual-machines-hotspot-jvm-vs-jrockit-jvm/
2. ^ https://www.injdk.cn/

苦逼社畜继续实时播报。

1.目前街上的私家车比昨天少了很多，但交通管制在某些路段形同虚设，警察有，路桩有，可是根本不查车呀……吉林大路和临河街口分区写着“有通行证”和“无通行证”两个边，结果过了分区隔离带没人查，又混到一起了……可能是早上七点半太早了？

2.这两天大规模新增数字，别理解成瞒报，清库存什么的，我个人理解单纯就是这三轮核酸清查出来的确诊和无症状人群，毕竟奥密克戎一轮核酸根本检测不出来，有的是密接在家隔离好几天终于阳性的，大家别对卫健委有那么多的成见，昨天群里区卫健委呼叫各医疗机构奉献医疗专业的志愿者，可以看出人手确实短缺，但检测点每个人都很辛苦，昨天晚上下楼倒垃圾的时候看见两个防护服窝在一个小屋里吃盒饭，作为给医疗人员提供行政服务的我看着很心酸，大部分志愿者和医护人员都是二十多的孩子，盼望多一分理解。

3.物资肯定没什么问题，工资嘛……等具体文件吧，我们明天发工资还不知道情况呢，那些没什么积蓄的年轻人和房奴、商户可难受了，不过很快就会过去。

4.医大一院也停诊了，我个人估计近日新增应该会逐渐减少，这核酸这么做要是还有漏的，那可就是科技上的失败了。

5.强烈建议给民营医疗机构的基层医务人员涨工资！我们行政类的可以再研究，都两年多了，基层医疗工作收入还是那些，付出和回报根本不对等，长春市民营医疗机构没有住院部的护士有几个赚三千五以上的？风险呢？

随便说说，这周我会继续实时播报的……

哪吒不知道，说说孙悟空。

看过某个物理专业人士的测算，孙悟空带着金箍棒坐筋斗云撞击物体，金箍棒的质量加上筋斗云的速度，会引发一场相当于60枚大伊万这样的超级大氢弹的爆炸。

孙悟空用金箍棒朝敌人腰部横扫，敌人会被直接腰斩，并且伤口部位由于温度过高而碳化。

金箍棒如果能无限缩小，由于质量不变，可以活生生制造一个黑洞。

孙悟空可以举起两座山在天上飞，也就是大概能举起十万亿吨的东西。

孙悟空的肉体强度可以抵挡接近光速的粒子轰击。

如果孙悟空加入复联，也就没有其他人什么事了。灭霸来到地球，悟空坐着筋斗云撞击灭霸，灭霸直接原地蒸发。