Performance improvement of a long-running Java workload just by changing from jdk8 to jdk13 with no other tuning. Can you guess what happened by setting Shenandoah or ZGC garbage collectors?


In a previous post we explained the benefits of moving a long time running java workload to OCI. Today we are showing the benefits we get by changing the jdk.

Procedure

The procedure was quite simple: We installed jdk13 in the hosts and started the nodes to see what happens. The first intent failed because the flag -XX:+AggressiveOpts is not supported in jdk13, so we removed it and started again. Hopefully no other changes were needed nor done and the process ended successfully. Let’s see the numbers:

JDKTIME
jdk88h34min
Open jdk136h38min
Oracle jdk136h24min

Conclusion 1

With jdk13 we got an improvement of 20%+just changing the SDK.

Testing brand new GC’s Algorithms

In a second step we tested the new garbage collectors. This features are not available yet in Oracle’s jdk, therefore we only tried with openjdk.

First, we set the ZGC [-XX:+UnlockExperimentalVMOptions -XX:+UseZGC] and started the process but it didn’t finished well throwing errors related to coherence:

20:37:42.654 ERROR e.m.s.p.AppGridPlanificador - Error recuperando progreso de tarea de vlam001 motor-2
 com.tangosol.io.pof.PortableException: Tried to execute method:getProgress but Entry is null, key:Identifier{0x0000016F0B0C76C80AFBEA0A3B3E93A2CC0BD3F3C0A246DCCF6F871F776F320D}
     at com.tangosol.io.pof.ThrowablePofSerializer.deserialize(ThrowablePofSerializer.java:57) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.io.pof.PofBufferReader.readAsObject(PofBufferReader.java:3316) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.io.pof.PofBufferReader.readObject(PofBufferReader.java:2604) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.io.pof.ConfigurablePofContext.deserialize(ConfigurablePofContext.java:376) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.util.ExternalizableHelper.deserializeInternal(ExternalizableHelper.java:2791) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.util.ExternalizableHelper.fromBinary(ExternalizableHelper.java:266) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ConverterFromBinary.convert(PartitionedCache.CDB:4) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ViewMap.invoke(PartitionedCache.CDB:24) ~[coherence.jar:12.1.2.0.0]
     at com.tangosol.coherence.component.util.SafeNamedCache.invoke(SafeNamedCache.CDB:1) ~[coherence.jar:12.1.2.0.0]
     at com.oracle.coherence.common.util.NamedCacheObjectProxy.invoke(NamedCacheObjectProxy.java:111) ~[coherence-common-12.1.0.jar:na]
     at com.sun.proxy.$Proxy11.getProgress(Unknown Source) ~[na:na]

In a second try we set Shenandoah with -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC but unfortunately the java processes crashed in the startup, don’t wanna lose more time for now so I give up happy with the improvement with zero effort…

Conclusion 2

For a long time running workload like the mentioned, garbage collectors didn’t provide any advantage compared with the one obtained by just swaping the jdk version.

Disclaimer

The results obtained here can’t be in any case extrapolated, things are not that simple and only idiots believe that one size fits all…

That’s all folks, hope it helps! 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.