RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u

[Ron Pressler]

There is no way moving off of Java isn’t at least 10x more costly than updating 
to JDK 15. Alternatively, there’s no way it’s cheaper than paying someone to 
offset the risk of new features with a support contract.

Again, without commenting on this particular decision (I don’t know the details 
of the Shenandoah patch), there is an easy, cheap solution for those who want 
new features. I think that much of the problem is a lack of education about how 
easy it is in most cases to run on the current JDK and that it is very often, the 
easiest, cheapest and safest approach.

— Ron

On 2 July 2020 at 22:14:04, Martijn Verburg (martijn.verburg at microsoft.com) wrote:



Cheers,  

Martijn  

________________________________  
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Martijn Verburg <Martijn.Verburg at microsoft.com>  
Sent: Thursday, July 2, 2020 13:32  
To: Gil Tene <gil at azul.com>; Andrew Haley <aph at redhat.com>  
Cc: Roman Kennke <rkennke at redhat.com>; Bernd Mathiske <mathiske at amazon.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Nilsen, Kelvin <kdnilsen at amazon.com>; Jiva, Azeem <javajiva at amazon.com>  
Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u  

Hi all,  

Appreciate all the excellent points being made here on both sides. I'll snip some of the long thread and reply to some of Gil's points below which I think speaks to the necessity angle.  

________________________________  
<snip>  

> - E.g. if we could show that without a new collector JDK 11  
> will show significant degradation from its current behavior  
> on some new, here, or obviously coming hardware configurations,  
> that could move this subject into the "gut-wrenching" mode I  
> talk about earlier in the thread.  
> [Sort of where TLS 1.3 is for 8u. Sort of where my thinking about  
> aarch64 for 8u is.]  

>> Putting on my Microsoft Hat - we have several 1st and 3rd party users that fall into this category.  

>>They're currently being forced to use an expensive architectural workaround or moving off the JVM altogether because  
>>there isn't a Garbage Collector in for Hotspot in Java 11 that can manage their mission-critical workloads.  

I'd like to offer a clarification on the above. There are of course GC's available for many Mission Critical workloads. However, there are a subset of those workloads where a low pause collector such as Shenandoah or ZGC are required to meet SLAs.  

I'd also like to acknowledge that ZGC does of course exist on 11 and we continue to evaluate that as well (and on tip). However, my understanding is that the lead maintainer (Oracle) is focused on tip (which is totally understandable!) and so maintenance on 11 does become more challenging.  

Cheers,  
Martijn