Switching from CMS to G1

[Aaron-He]

Now, the jvm Namesrv running on uses CMS, while the jvm Broker running on uses G1.
Maybe we could switch from CMS to G1, reasons are as follows:

1. Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2. As The latest release version(4.6.0) couldn't normally run on java 11 #1688 mentioned, Namesrv cannot run on JDK 11, the reason is some options about CMS has been removed. But G1 was introduced in Java 7, and becomes default GC in the higher version JDKs(after version JDK 9).
3. The G1 can collect both the young and the old generation.
   ...

Undeniably, the G1 doesn’t perform well with small heaps. However, the heap memory size Namesrv uses is 4G, it may not be small. Also, full GCs can be triggered when humongous objects (objects over 50% of the size of a region) can’t be allocated due to a lack of space(no continuous regions available).
However, 4G heap Memory for Namesrv as an example, the G1 can still perform well. According to best tuning practices( heap memory is divided into about 2000 regions), we can set one region 2M. Use jmap tool to get heap dump file of Namesrv in the test environment(2m-2s-async brokers, 2 namesrv), use visualvm tool to analysis the file, the 10 biggest objects are as follows:

Class Name	Retained Heap
sun.misc.Launcher$ExtClassLoader#1	1,223,336
java.util.Vector#45	658,138
java.lang.Object[]#59741	658,102
java.util.concurrent.ConcurrentHashMap#75809	369,344
java.util.concurrent.ConcurrentHashMap$Node[]#18955	369,244
class io.netty.buffer.ByteBufUtil$HexUtil	358,480
io.netty.buffer.PoolThreadCache#1	339,839
io.netty.buffer.PoolThreadCache#16	339,758
io.netty.buffer.PoolThreadCache#2	339,434
io.netty.buffer.PoolThreadCache#6	339,434

In summary, there is no performance penalty for switching from CMS to G1.

[duhenglucky]

@Aaron-He good suggestion, could you pull a request to polish this?

[Aaron-He]

@duhenglucky Glad to.

[zongtanghu]

If rocketmq can support serveral kinds of JDK versions, then more and more people can used rocketmq in different platforms.

[token01]

Do you have the result of the discussion？

[lizhimins]

Good suggestion

[Aaron-He]

I performed verification tests. There is no problem with GC switching, but high-level JDK （after JDK1.8）is not supported because of modularity and class loader.
我进行了验证测试，GC替换没有问题，但是由于模块化和类加载器等原因，高版本JDK不支持。

[JerryChaox]

I performed verification tests. There is no problem with GC switching, but high-level JDK （after JDK1.8）is not supported because of modularity and class loader.
我进行了验证测试，GC替换没有问题，但是由于模块化和类加载器等原因，高版本JDK不支持。

According to the migration guide:

1. https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-A78CC891-701D-4549-AA4E-B8DD90228B4B
2. https://docs.oracle.com/en/java/javase/11/migrate/index.html#JSMIG-GUID-A78CC891-701D-4549-AA4E-B8DD90228B4B

Starting from JDK 9

Class and resource files previously stored in lib/rt.jar, lib/tools.jar, lib/dt.jar and various other internal JAR files are stored in a more efficient format in implementation-specific files in the lib directory.

The javac compiler and java launcher will exit if the java.ext.dirs system property is set, or if the lib/ext directory exists. To additionally check the platform-specific systemwide directory, specify the -XX:+CheckEndorsedAndExtDirs command-line option. This causes the same exit behavior to occur if the directory exists and isn’t empty. The extension class loader is retained in JDK 9 and is specified as the platform class loader (see getPlatformClassLoader.)

So starting from jdk9, it's necessary to remove this line for JAVA_OPT:
JAVA_OPT="${JAVA_OPT} -Djava.ext.dirs=${JAVA_HOME}/jre/lib/ext:${BASE_DIR}/lib"
and rocketmq does not need the extension mechanism.

Moreover, it's necessary to check if rocketmq break the rules of this new specification (JEP220).

See JEP 220: Modular Run-Time Images.

[github-actions]

This issue is stale because it has been open for 365 days with no activity. It will be closed in 3 days if no further activity occurs.

[github-actions]

This issue was closed because it has been inactive for 3 days since being marked as stale.