Shenandoah on JDK11

[Aditya Mandaleeka]

Thank you Roman for this very helpful info. Yes, this answers the questions I have for now.

Thanks,
Aditya

-----Original Message-----
From: Roman Kennke <rkennke at redhat.com> 
Sent: Thursday, December 5, 2019 2:10 PM
To: Aditya Mandaleeka <adityam at microsoft.com>; shenandoah-dev <shenandoah-dev at openjdk.java.net>
Subject: Re: Shenandoah on JDK11

Hi Aditya,

> I'd like to understand the current state of Shenandoah on JDK11. I see that there is a backported version being maintained at shenandoah/jdk11 which is great (thank you!). I'm interested in specifically learning more about the following:
> 
> - How reliable/stable is this configuration today in your experience?

The shenandoah/jdk11 repository is the basis of what we (Red Hat) base our RPMs on, and ship to our customers, and we wouldn't do that if we hadn't enough confidence in doing so :-) We establish that confidence by running regression tests very frequently, basically before each change going in. We also have an extensive suite of tests running nightly in our CI. Overall, we don't seem to get many complaints about it.

> - What is the best way for a newcomer to track what has been backported and what hasn't?

Aleksey wrote a nice program called 'backports monitor' which tracks the various states and flags in Jira issues and compiles a list of items that are backported and need to be backported. For example, the following tells you what's in jdk14 (the jdk/jdk repo) but not in 11u, 8u or sh/11 or sh/8:

https://builds.shipilev.net/backports-monitor/label-actionable-gc-shenandoah.txt

Find more of such lists here:
https://builds.shipilev.net/backports-monitor/

In general, we are backporting anything that is sensible, and try to keep the various versions as much in sync as possible. There are things that simply lack the infrastructure in older versions which don't make sense to backport, for example the recent 'concurrent class unloading'
work that just went into jdk14. However, we only backport changes after certain grace period and only when we are reasonably certain that they don't break other things (as confirmed by our CIs and perhaps manual test runs and bug reports, etc).

> - What do we know about the performance gap between shenandoah/jdk11 and Shenandoah on tip? I see that the "Shenandoah 2.0" barrier changes and extra word elimination have made it over to 11, but for other changes in Shenandoah (and its interactions with the rest of Hotspot) that can impact performance, is there an established way they are being analyzed and prioritized for backporting?

In general, the performance gap between the various backport versions should be minimal. There may be significant enhancements in other parts of Hotspot that may affect Shenandoah GC performance. For example, there is loop strip mining in jdk11 and up but which is not in jdk8, and it can, in some cases, severely affect time-to-safepoint and therefore latency of workloads.

Does that answer your questions?

Thanks and best regards,
Roman


> Thanks in advance for your time.
> 
> -Aditya
>