0

In containerized environments we have huge waste in terms of resources when use java. In terms of vertical scaling we need to have an optimized JVM. Are there any public comparison tests available of vertical scaling and memory usage of OpenJ9 and HotSpot G1

Ruslan
  • 395
  • 3
  • 12
Kamen Tarlov
  • 11
  • Jelastic initiated and sponsored development of a patch to OpenJDK which improves elasticity and enables fully automated vertical scaling of Java applications that rely on G1 garbage collector. This work introduces new command line options for heap sizing that allows the JVM to scale its memory resources vertically. In particular, the proposed solution is to promptly return unused committed memory to the operating system. The offered solution is already implemented in the OpenJDK 12. – Virtuozzo Apr 17 '19 at 09:56
  • This improvement will allow Java users to save a significant amount of resources and thus money, as well as help cloud providers to better utilize their infrastructure and introduce more flexible billing model based on real usage not on the VM limits. Read more here https://jelastic.com/blog/elastic-jvm-vertical-scaling/ – Virtuozzo Apr 17 '19 at 09:57
  • 1
    why not try both and see which works best for you both for performance, stability, security, support, etc. etc. etc.? These latter things are generally far more important than mere raw performance. – jwenting Apr 17 '19 at 11:28
  • 1
    Eclipse OpenJ9 is a low memory footprint JVM, so I expect it to scale vertically better than Hotspot. for reference: https://www.eclipse.org/openj9/oj9_performance.html https://blog.openj9.org/2018/06/15/eclipse-openj9-performance-a-bake-off-on-windows/ https://medium.com/criciumadev/new-open-source-jvm-optimized-for-cloud-and-microservices-c75a41aa987d – Ashutosh Apr 17 '19 at 12:48

1 Answers1

2

Is OpenJDK 12 better than J9 for vertical scaling?

It's hard to answer at this stage as there are no publicly available comparison tests. Now both JVMs look good in terms of elasticity.

There is one known issue related to monitoring mechanism of the committed RAM.

With OpenJ9 you have to do it on OS level 

To test vertical scaling with respect to memory in OpenJ9 I recommend to monitor the resident-set-size (RSS) of a Java process with a script like this:

while true; do
   sleep 1
   ps -orss --no-headers --pid $1
done

While OpenJDK allows to monitor the committed RAM inside a code running in JVM, and also you can use standard tools like VisualVM or others.

Ruslan
  • 395
  • 3
  • 12
  • OpenJ9 also supports the `ManagementFactory.getMemoryMXBean()`. It's important to note that the RSS is the total committed memory for the process and will report a very different number than the MXBean as the the bean only reports the memory related to the GC'd heap – Dan Heidinga Apr 17 '19 at 12:54
  • @DanHeidinga, as I understand based on the mentioned github conversation, the committed RAM we get from getMemoryMXBean() will be higher than it is in reality. Am I wrong? – Ruslan Apr 17 '19 at 16:31
  • The amount of address space that has been committed to the gc heap is reported by the MXBean. This is different than the amount of physical memory (RSS) in use. I would expect the RSS to be more accurate for all JVMs than the MXBean – Dan Heidinga Apr 22 '19 at 16:02