本帖最后由 1a2s3d4f1 于 2020-11-29 00:40 编辑
我用了一个jar测试openj9的gc时，发现https://steinborn.me/posts/tuning-minecraft-openj9里提的一些参数可能没用
按openj9的doc的参数介绍和我做的测试，大概内容如下：
旧区域与新区域有个关系，Xmns+Xmos=Xms Xmnx+Xmox=Xmx,所以设置Xms=Xmx时，Xmos+Xmns=Xmox+Xmnx，当Xmx=Xms时，Xmns就决定了新区域最大大小，设置Xmnx似乎就失效了，在参数-Xms4096M -Xmx4096M -Xmns2048M -Xmnx3276M -Xgc:concurrentScavenge -Xgc:dnssExpectedTimeRatioMaximum=3 -Xgc:scvNoAdaptiveTenure -Xdisableexplicitgc 中，新区域最大就算Xmns的数值（2048M）
用测试jar测试内存，设置Xmx=Xms,Xmns=1M时，分配区域就只是用1M，无法扩大（可能不准确），所以参数可改为：
复制代码不设置Xms=Xmx时，可用Xmns取Xms的50%,像那个教程里那样，那就个教程的新区域大小占总内存的一半，80%似乎不能扩张到
帖子中的新区域（Nursery区域），旧区域（Tenure区域）关系见openj9下doc的gc图，mc高版本短命垃圾多，openj9默认的25%Nursery区域有时就不太够了。
1.16的线程问题导致mc启动后会占用大量cpu一段时间，用这个mod可解决占用问题。可保留Xmnx，去除Xmns和Xms来让openj9的分配区域上限更大些
我用了一个jar测试openj9的gc时，发现https://steinborn.me/posts/tuning-minecraft-openj9里提的一些参数可能没用
按openj9的doc的参数介绍和我做的测试，大概内容如下：
旧区域与新区域有个关系，Xmns+Xmos=Xms Xmnx+Xmox=Xmx,所以设置Xms=Xmx时，Xmos+Xmns=Xmox+Xmnx，当Xmx=Xms时，Xmns就决定了新区域最大大小，设置Xmnx似乎就失效了，在参数-Xms4096M -Xmx4096M -Xmns2048M -Xmnx3276M -Xgc:concurrentScavenge -Xgc:dnssExpectedTimeRatioMaximum=3 -Xgc:scvNoAdaptiveTenure -Xdisableexplicitgc 中，新区域最大就算Xmns的数值（2048M）
用测试jar测试内存，设置Xmx=Xms,Xmns=1M时，分配区域就只是用1M，无法扩大（可能不准确），所以参数可改为：
- -Xms4096M -Xmx4096M -Xmns2048M -Xgc:concurrentScavenge -Xgc:dnssExpectedTimeRatioMaximum=3 -Xgc:scvNoAdaptiveTenure -Xdisableexplicitgc
帖子中的新区域（Nursery区域），旧区域（Tenure区域）关系见openj9下doc的gc图，mc高版本短命垃圾多，openj9默认的25%Nursery区域有时就不太够了。
1.16的线程问题导致mc启动后会占用大量cpu一段时间，用这个mod可解决占用问题。可保留Xmnx，去除Xmns和Xms来让openj9的分配区域上限更大些
感觉不懂你在说啥