BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News AdoptOpenJDK Welcomes Dragonwell

AdoptOpenJDK Welcomes Dragonwell

This item in japanese

Lire ce contenu en français

Bookmarks

AdoptOpenJDK and Alibaba announced that the Alibaba Dragonwell JDK will be built, tested, and distributed using AdoptOpenJDK's infrastructure. This means users have more options and can opt to use Alibaba Dragonwell because of its unique features such as coroutine and warmup support.

Alibaba's Dragonwell is a downstream version of OpenJDK, that has some significant features that are not available in the OpenJDK mainline. Alibaba describes it as an OpenJDK build optimized for e-commerce, financial, and logistics applications. Alibaba uses Alibaba Dragonwell to run its applications on 100,000+ servers.

In 2019 Alibaba Dragonwell was made open source and it's available for free. Linux x86-64 is officially supported however, there's also an aarch64 build available and there is an experimental version for Windows. Alibaba mentions that it will provide long term support, but the exact period hasn't been defined.

Builds for Alibaba Dragonwell 8 and 11 will be published on the AdoptOpenJDK website. This means the AdoptOpenJDK API can be used to download the binaries. This is particularly useful for organizations that automate the retrieval of new binaries.

One of the unique features of Alibaba Dragonwell is JWarmup. JWarmup tries to reduce the warmup performance challenges caused by JIT compilation. The solution uses precompiled hot methods to improve performance. To achieve this, two phases are defined: the pre-run and the normal run.

In the pre-run phase profiling data for the hot methods is recorded during a load test and stored in a file on disk. That file is used during the normal run where the JIT thread compiles the methods in the file to native versions. Now those methods are executed natively from startup instead of interpreted. This reduces the warmup phase of an application which results in improved performance for applications that just started.

These types of ideas to reduce warmup effects have been discussed for many years - for example, Azul Systems have a technology in their Zing JVM called ReadyNow! which also reuses compilation data from previous runs. The addition of tiered compilation and the jaotc compiler also represent steps in the direction of improving startup performance by reducing or sidestepping the amount of interpreted mode that is executed.

Another interesting feature is the Wisp2 coroutine support. Wisp2 maps Java threads to coroutines instead of kernel-level threads. The performance of the application is potentially improved as many coroutines can be scheduled on a small number of core lines. This reduces the scheduling overhead and can show an improvement depending on the workload being run.

The Wisp2 engine is similar in some respects to the aims of Project Loom, which also tries to remove the bottleneck of the number of live threads by allowing developers to "virtualize" their threads and multiplex them onto a smaller number of platform threads that use similar approaches to coroutines.

The central idea of Wisp2 is that (unlike Loom) it works out of the box on existing code by enabling it with these Java arguments:

java -XX:+UnlockExperimentalVMOptions -XX:+UseWisp2

As Wisp2 requires no source code changes, the migration cost is low. Developers don't need to implement coroutines themselves and existing Java concurrency features can still be used.

However, not all applications benefit from Wisp2 and the impact of automatically moving all threads to coroutines can be very large (and not necessarily positive).

I/O intensive applications where tasks are blocked on events and then scheduled can benefit from the coroutine support. On the other side, CPU intensive applications will probably not benefit from coroutines. The easiest way to find out if an application benefits from Wisp2 is to enable the support and run a performance test.

Alibaba is actively working on contributing these and other features and patches to the upstream OpenJDK. For example, JWarmup is described in a Java Enhancement Proposal (JEP), but it's still in draft state at the time of writing.

AdoptOpenJDK and Alibaba Dragonwell are two of the most well-known distributions based on OpenJDK, but there are many more options such as: Amazon's CorrettoSap's SapMachineBellSoft's LibericaAzul's Zulu, and ojdkbuild. The organizations deliver JDKs and JREs with different features and patches. Next to that, each organization determines its own support levels, some of which are paid. This gives customers more freedom as they can choose their preferred JDK based on the features and the support they need.

Updated: Corrected reference to the TCK status of Alibaba Dragonwell

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • "scheduling overhead" is actually "context switch" overhead

    by Enrique Benito,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Scheduling logic and overhead is similar in kernel threads and "co-routines", but switching from kernel thread to kernel thread after scheduling requires refreshing cache lines in CPU from "slow" (compared to internal CPU cache) RAM memory. Performance can degrade very fast if different I/O "channels" are being mapped to different kernel threads, since CPU will pass more time refreshing cache lines than doing effective work.
    In linux, the "perf" can be used to display context switches and cache misses (and CPU migrations, ...) like:

    "perf stat -- java --jar ... "

    This can help to decide if switching to co-routines implementation is worth it.

  • Dragonwell 11 and TCK

    by Simon Ritter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Although Alibaba has signed the OCTLA for Java SE 8, they have not signed for Java SE 9 and later. They, therefore, do not have access to the TCK for JDK 11 so DragonWell 11 is *not* TCK tested, as stated in the article.

  • Re: Dragonwell 11 and TCK

    by Johan Janssen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you Simon for the feedback, I somehow missed that distinction.

    The article is updated and now mentions specifically that 8 is TCK tested.

  • Re: Dragonwell 11 and TCK

    by li lshy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Johan,
    Thanks for your article and an excellent introduction to Alibaba Dragonwell. I have two cents:
    1. Can you add 'Alibaba' before Dragonwell for all the occurrences?
    2. The recent release of Alibaba Dragonwell ships the 'Wisp' feature, which breaks the TCK. I'd suggest removing the claim about Alibaba Dragonwell 8 TCK certification. Alibaba Dragonwell team is working on this and will update the information on the Alibaba Dragonwell website once the issue is resolved.

  • Re: Dragonwell 11 and TCK

    by Johan Janssen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi li lshy,

    Thank you for the remarks. I've just adjusted the article.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT