Looking at some of our internal documentation seems like we are looking to move towards Azul Zulu[0] for our JRE/JDK. Any have any experience with this or know if its license is compatible with Apache projects?
-d [0] - https://www.azul.com/downloads/zulu-community/?&architecture=x86-64-bit&package=jdk On 1/30/20, 11:21 AM, "Markus Thömmes" <markusthoem...@apache.org> wrote: FWIW, the UUID entropy workaround where not JVM specific IIRC but OS dependent, as we switched from random to urandom as a source of entropy. I don't feel strongly for either OpenJDK vs. OpenJ9, but it'd be nice to understand where the degradation comes from and thus make a deliberate decision to choose one over the other based on that research. If anything, that might be very valuable input for the OpenJDK community to fix this regression, maybe? That research could also help us better understand where the bottlenecks of our system are and thus point us towards improvements to be made. We could of course switch to OpenJ9 to bypass the degradation if we want to move to JDK11 quickly. Thanks for sharing the results, Markus Am Di., 28. Jan. 2020 um 18:24 Uhr schrieb Martin Henke <martin.he...@web.de >: > Rodric, > > UUID creation was just an example from the past where workarounds were > needed to circumvent waiting for enough entropy for the random numbers used > for UUID creation. As said we did no further investigation. > > Yes. OpenJ9 is Apache licensed and distributed via AdoptOpenJDK. There are > no further changes needed. > > Regards, > Martin > > > Am 28.01.2020 um 18:09 schrieb Rodric Rabbah <rod...@gmail.com>: > > > > Thanks Martin for sharing the results with the community - That's a > steep > > performance degradation. > > Open J9 is Apache licensed. Are other changes needed? > > > > You hinted at uuid - do you know that's implicated or a guess? > > > > -r > > > >> On Tue, Jan 28, 2020 at 8:05 AM Martin Henke <martin.he...@web.de> > wrote: > >> > >> Folks, > >> > >> as indicated, we performed performance tests of the OpenJDK upgrade PR > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fopenwhisk%2Fpull%2F4706&data=02%7C01%7Cmcweeney%40adobe.com%7C763c5b76ea74463e572808d7a5b99f7d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637160088976247846&sdata=MYWLUKkh733ckOEVNCL5727Y%2FIgyi0rcz5P0WJ4qjy0%3D&reserved=0 > >> in our performance test environment (we are using the exact set of > Gatling > >> tests that are contributed to Openwhisk). > >> > >> Though our first impressions looked good, we found severe degradations > in > >> the latency and warm invocation tests afterwards. > >> > >> Latency tests dropped to around 50% of the JDK8 results, warm invocation > >> to a staggering 25%. > >> These results were stable with using the original and the updated > Gatling > >> image and switching to parallelGC on OpenJDK11. > >> > >> Since GC does not seem to matter, the degradation might be caused by a > >> changed > >> implementation in the OpenJDK 11 (e.g. UUID generation). > >> We did not perform any deeper research. > >> > >> Next we tried to change to use the OpenJ9 JDK11 instead of OpenJDK. > >> Change in common/scala/Dockerfile: > >> " > >> -FROM adoptopenjdk/openjdk11:x86_64-alpine-jdk-11.0.3_7 > >> +FROM > >> adoptopenjdk/openjdk11-openj9:x86_64-alpine-jdk-11.0.5_10_openj9-0.17.0 > >> " > >> With OpenJ9 in default configuration all performance metrics were > looking > >> good again. > >> We did not see any degredation anymore. > >> > >> In the light of these test results, I herewith would like to start the > >> discussion to base the JDK update PR > >> to openJ9 JDK11. > >> > >> Kind Regards, > >> Martin > >> > >
