Tag: openj9

encoding in jdk openj9 docker images

Recently I was looking into encoding problems and I was really surprised to find this:

docker run –rm adoptopenjdk/openjdk11-openj9:jre-11.0.2.9_openj9-0.12.1-alpine java -XshowSettings 2>&1 | grep encoding

file.encoding = ANSI_X3.4-1968
file.encoding.pkg = sun.io
ibm.system.encoding = ANSI_X3.4-1968
os.encoding = ANSI_X3.4-1968
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = ANSI_X3.4-1968

Even adding environment variables like LC_ALL or LANG did not help 🙁

docker run –rm -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 adoptopenjdk/openjdk11-openj9:jre-11.0.2.9_openj9-0.12.1-alpine java -XshowSettings 2>&1 | grep encoding

But the issue was fixed with a more recent version of the image:

docker run –rm adoptopenjdk/openjdk11-openj9:jre-11.0.6_10_openj9-0.18.1-alpine java -XshowSettings 2>&1 | grep encoding

file.encoding = UTF-8
file.encoding.pkg = sun.io
ibm.system.encoding = UTF-8
os.encoding = UTF-8
sun.io.unicode.encoding = UnicodeLittle
sun.jnu.encoding = UTF-8

Be aware of this insides of the images you use!

Happy coding

Memory Footprints of hello-world microservices

I was curious reading about openj9 as a JVM being high performance and using a low memory footprint. I was working in a project, where the environment of software systems consisted of around 30 Java Applications, a few running on tomcat, a few on weblogic and the most running on dropwizard microservice framework. The desirable goal for every developer was to start the complete platform on his local notebook and therefor a virtalbox image was build using vagrant. As there were so many applications, each microservice itself consumed around 250MB of RAM and with the number of services growing we already hit 24GB image size of the virtualbox image. I found the blogpost https://codeburst.io/microservices-in-java-never-a7f3a2540dbb which describes the same issue and that if you those java microsevices in a cloud infrastructure, you would even have to pay even more money only because of the memory footprint.

Luckily there was somebody doing a comparsion of openj9 vs hotspot VM in his two blogpots https://royvanrijn.com/blog/2018/05/openj9-jvm-shootout/ and https://royvanrijn.com/blog/2018/05/openj9-hotsport-specjvm2008/ already. He was is showing some benchmarks and results.

My own simple comparison

I tested it on my own (just for curiosity) and came to the same result. In terms of memory consumption, there is a potential improvement with openj9 as JVM alternative.

I picked three helloworld examples using maven archetypes from dropwizard, helidon and Spring Boot.

First I packacked them into docker images using adoptopenjdk/openjdk8-openj9:alpine-slim on the one hand and adoptopenjdk/openjdk8:alpine-slim on the other hand.

Then I compared memory consumption using application metrics and dockers stats and could have a rough idea of the differences. Here is the result of the dropwizard app:

openj9 without any parameters to the jvm:

  • jvm.memory.heap.used = 10563328 B, jvm.memory.total.used = 37838048
  • docker container = 48.55MiB

hotspot without any parameters to the jvm:

  • jvm.memory.heap.used = 28511520 B, jvm.memory.total.used = 61381328
  • docker container = 118.3MiB

Conclusion

Whether you have the goal of running your complete software on your developer laptop or you want to save money running your services in a public cloud, openj9 provides a possibility to reduce the memory footprint of your java application by around 50%.

As it was mentioned in the other blog posts, there are also a few downsides with this, but if you test everything and the requirements (in terms of computation performance) are met, you should give it a try.