Java 11 vs Java 8 | HotSpot vs OpenJ9

Discussion in 'Performance Tweaking' started by Gryent, Feb 6, 2020.

  1. I was curious about this topic, because when searching about this topic I wanted to check that JVM was better to run a minecraft server but I didn't find any, so I made some tests with the following JDK:

    -AdoptOpenJDK 8 OpenJ9
    -AdoptOpenJDK 8 HotSpot
    -AdoptOpenJDK 11 OpenJ9
    -AdoptOpenJDK 11 HotSpot

    I have tested the server and I have always been using AdoptOpenJDK 11 HotSpot, but it was always reaching the maximum RAM limit or higher than the one I assigned to it, so I decided to do these tests so that you can see the difference in RAM usage.

    Start-up Parameters:

    java -Xms2G -Xmx2G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=100 -XX:+DisableExplicitGC -XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:G1MixedGCLiveThresholdPercent=35 -XX:+AlwaysPreTouch -XX:+ParallelRefProcEnabled -Dusing.aikars.flags=mcflags.emc.gs -jar paperclip.jar nogui

    Paper-90 Build
    38 Plugins
    A world of approximately 3-6 players


    Java 8 OpenJ9
    [​IMG]
    Java 8 HotSpot
    [​IMG]
    Java 11 OpenJ9
    [​IMG]
    Java 11 HotSpot
    [​IMG]

    In conclusion I will start using Java 11 OpenJ9 because of its low RAM consumption and stable TPS, lol.
     
  2. Phoenix616

    Resource Staff

    I hope you realise that the flags you are using are made for HotSpot and have mostly no effect on OpenJ9. I suggest taking a look at this article for some info regarding OpenJ9 tuning.
     
    • Agree Agree x 3
    • Like Like x 1
    • Informative Informative x 1
  3. I do not recommend making your decisions based on memory usage. Achieving the highest execution speed on a single thread is what matters most.
    As for what version, I recommend going always with the latest LTS, that is 11 at the time of writing.
    Personally I would use OpenJDK, which is available as a package in most popular Linux distributions.
     
    #3 System, Feb 7, 2020
    Last edited: Feb 7, 2020
    • Agree Agree x 1
  4. Two completely different things, going off of memory usage is perfectly fine when you're trying to make it a lightweight as possible.
     
  5. MiniDigger

    Supporter

    java 13 (14 soon, hype!) > java 11 > java 8

    hotspot > openj9 (mostly cause IBM and I had a reeeaaaallly bad time with older versions of j9 at work, I will never ever touch that again)

    but like, non of this really matters for a small server like yours.

    any reason you dont suggest using the latest stable release?
     
  6. Mind adding some tests that use shenandoah gc (hotspot)? Would be interesting to see how that compares to aikar's g1.
     
  7. MiniDigger

    Supporter

    I doubt that you will see any improvements with shenandoah. It doesnt have as much throughput as g1gc (some ppl suggest -10%) and you can get low pause times on g1gc too:
    upload_2020-2-7_9-20-23.png
     
  8. Well, yes, reducing memory usage is fine if your host is memory constrained.

    Unless you need to make use of the features introduced in the latest releases, I see no point in upgrading.

    I recommend using Shenandoah GC in order to achieve the best performance when running on a beefy host, because of its low pause times (causing lag spikes that last for ~2ms vs up to ~100ms when using G1 with Aikar's flags).
     
    #8 System, Feb 7, 2020
    Last edited: Aug 18, 2020
  9. MiniDigger

    Supporter

    if you have 100ms pause times, something seems wrong
     
  10. I remember sometimes seeing long tick durations when minor GCs occur. Anyway, Shenandoah avoids old-gen spikes and does not require manual tuning.
     
    #10 System, Feb 7, 2020
    Last edited: Aug 18, 2020
  11. Shenandoah is great, and as mentioned, doesn't suffer from the 100ms GC pauses every ~15 seconds from G1GC. Though this is only saving 2 ticks (100ms) over a duration of 300 ticks (0.006% of ticks to GC) - so changing JVM is no magic fix-all for poor performance.

    Pertaining to the OP - memory can be kept low on any JVM, what's important is the CPU time spent on keeping your memory low. You should find a tradeoff between memory usage and GC CPU time. Additionally, I wouldn't conclude your tests solely off of htop screenshots, I suggest using a java profiler (YourKit, VisualVM, JProfiler, etc.) and compare GC time for each JVM.