Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Why do you need to use the JDK 11 instead of 8?


Gonchik in touch. 

As we know Garbage-First is quite a popular garbage collector nowadays. At least more and more articles, product documentation mention G1GC. 

Today, I’d like to share a story about leaked Jira Service Desk DC (3 nodes) with more than 20 apps from the marketplace, quite a lot of groovy scripts (405 files), 6 in-house apps. Also, it's continue of previous article.

One of the instances every night do import files into the “Insight” app, those asset management includes too many assets around 1 mln, as it’s daily import history of objects can grow as well.

Let’s focus only on importing procedure, we had 1 dedicated instance with 32GB heap for jdk8u282-b08 and G1GC. During import find out the next behaviour:

# cat atlassian-jira-gc.0.current| grep -i "full"

2021-03-30T21:13:19.462+0300: 934.828: [Full GC (Allocation Failure)  31309M->23165M(32768M), 58.7721842 secs]
2021-03-30T21:14:31.997+0300: 1007.363: [Full GC (Allocation Failure)  28965M->23085M(32768M), 53.9423610 secs]
2021-03-30T21:15:58.527+0300: 1093.893: [Full GC (Allocation Failure)  29277M->23233M(32768M), 55.0332227 secs]
2021-03-30T21:17:18.147+0300: 1173.513: [Full GC (Allocation Failure)  29249M->23469M(32768M), 56.4150710 secs]
2021-03-30T21:18:28.114+0300: 1243.480: [Full GC (Allocation Failure)  29253M->23540M(32768M), 56.5262454 secs]


After just updating the  jdk to jdk-11.0.10+9, we can find improvement only for the full GC activity. 

# cat atlassian-jira-gc.1.log.0 | grep -i "full "

[2021-04-07T07:58:29.710+0300] GC(3745) Using 11 workers of 11 for full compaction
[2021-04-07T07:58:29.710+0300] GC(3745) Pause Full (G1 Evacuation Pause)
[2021-04-07T07:58:39.163+0300] GC(3745) Pause Full (G1 Evacuation Pause) 32768M->24074M(32768M) 9452.818ms
[2021-04-07T08:54:55.518+0300] GC(6005) Using 11 workers of 11 for full compaction
[2021-04-07T08:54:55.518+0300] GC(6005) Pause Full (G1 Evacuation Pause)
[2021-04-07T08:55:05.032+0300] GC(6005) Pause Full (G1 Evacuation Pause) 32734M->25724M(32768M) 9513.629ms
[2021-04-07T08:55:32.812+0300] GC(6070) Using 11 workers of 11 for full compaction
[2021-04-07T08:55:32.812+0300] GC(6070) Pause Full (G1 Evacuation Pause)
[2021-04-07T08:55:41.549+0300] GC(6070) Pause Full (G1 Evacuation Pause) 32714M->25595M(32768M) 8736.933ms

So especially did not change the parameters in that article, to make GC improvements with next parameters: InitiatingHeapOccupancyPercent, UseCompressedClassPointers, UseCompressedOops, MaxGCPauseMillis, OmitStackTraceInFastThrow, UseStringDeduplication.

What’s happened, why does Full GC on JDK8 work so slow? If you look on htop, you can see only 1 CPU is busy. 


After looking at the picture, the next JEP-307 (ParallelGC for FullGC), is a motivating upgrade to Java 11. 

And, please, don’t forget to checkout compatibility on the Supported platforms page.

In conclusion, if you’re using G1GC in JRE 8, you can meet with small problems once Full GC will be called and your system can be freezed for a long time instead of JRE 11.


Hope it helps to make a decision.




UPD: Don't forget to test on your setup the JDK11. 


Taranjeet Singh Community Leader Apr 16, 2021

@Gonchik Tsymzhitov Thanks for sharing this useful update regarding JDK 11 capabilities in regard to Garbage Collection. This is really good to know.

Like Gonchik Tsymzhitov likes this

@Taranjeet Singh  You're welcome!

Just to remind people to test - a number of us have seen problems with JDK11 deployments.

It's completely subjective (hence the comment about testing - it will probably work, but you should never just jump to a new thing just because it might be better.  Test that jump), but Jira on JDK11 failed us on work logs, both directly and via Tempo, it broke some user macros in confluence, and caused problems with some of the apps.

I am not saying "don't use it", I'm saying "make sure it doesn't break stuff before using it"

@Nic Brough _Adaptavist_  Thanks, added info about testing, of course it's helpful. 

Could you provide more info about your use cases? Just interesting to me, how was developed which reflected app. 

if developers used the low level implementation (JAX, CORBA or some apps still use the sun.misc.unsafe) and approved as DC compatible, or supported the version of platform which is supported Java 11. 

Maybe need to improve here validation process, what do you think?

I'm not sure there's a lot more to add.

Install Jira or Conflluence on a server that has JDK11 on it.  Test them.  Things do not work.  Install JDK8 and set the systems to use that, and the things that failed on JDK11 work fine.  Literally - one JDK verstion fails, the other does not.  I don't think it matters exactly which bits fail, just that you need to test whether everything works or not.  (I've personally seen velocity, work logs and user macros fail, but other people have seen other things)

@Nic Brough _Adaptavist_  Thanks for that. 

Do you have more detail like version of platform and info about version of modules? 

What kind of releases of JRE did you use it, I mean minor releases? also, what kind of built did you use ? 

Several versions of Jira 8.x off-the-shelf, several JDKs, and an assortment of Linux kernels (we've also seen problems on Windows, but as no-one in their right mind uses Windows, we fixed a lot of stuff by switching people over to a proper operating system)

@Nic Brough _Adaptavist_  Okay, 8.x had problem with several JDKs, and Linux kernel. Could you share the exact setup with version, please?

I would like test it and understand what was a cause. Especially, interesting the how the kernel related to that situation. Anyway I can setup the same kernel, to me quite interesting to understand the exact cause. 

As you aid fixed, do you mean, after reporting to vendor (Atlassian or app) they adjusted code which started to work with that,  am I right?

The exact setup is not relevant because there were many differing factors.  There were several versions of linux installs, several variants of the JdK 11 and several off-the-shelf installations of Jira and Confluence (mostly the long-term-support releases) that had problems.  All reported to the relevant vendors.

Some were fixed by using different versions of Jira or Confluence, others by using a different Java.

The configuration was not the problem, it was faults in the software.  All I'm saying is that people need to test, not just assume everything works automatically.


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you