Announcing Graal Development Kit for Micronaut 4.3.7

Today, we are announcing Graal Cloud Native is now Graal Development Kit for Micronaut, and the general availability of Graal Development Kit for Micronaut 4.3.7 based on Micronaut framework 4.3.7. Let us look at some of the notable changes in this release.

A New Name

Thanks to feedback from our users, and to better align with the Micronaut framework, we are renaming Graal Cloud Native to Graal Development Kit for Micronaut. We believe the new name clearly articulates the project's vision and purpose. We expect to complete the renaming process soon.

Graal Development Kit for Micronaut (GDK), previously Graal Cloud Native (GCN), is an Oracle build of the open source Micronaut® framework. GDK provides a curated set of Micronaut framework modules that simplify cloud application development, are designed to be compiled ahead-of-time with GraalVM Native Image, and are fully supported by Oracle. GDK modules provide platform-independent APIs and libraries for a set of core public cloud services across Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), and Google Cloud Platform (GCP), with Microsoft Azure coming soon.

GDK enables you to easily build portable cloud native Java microservices that start instantly and use fewer resources to reduce compute costs. You can write Java applications once and run them on any supported public cloud—OCI, AWS, and GCP—and avoid cloud vendor lock-in.

Bill of Materials with Micronaut Framework 4.3.7

In this release, we have updated the Micronaut framework version from 4.2.1 to 4.3.7 applying patches to several Micronaut modules. See Micronaut Framework Releases for more information. The GDK 4.3.7 bill of materials contains specific versions of Micronaut framework 4.3.7 modules and their dependencies that are compatible and tested together. This reduces the risk of library incompatibility and version mismatches, and saves you from having to test and figure this out for yourself.

Gradle:

dependencies {

    micronautBoms(platform("cloud.graal.gcn:gcn-bom:4.3.7.2"))

    ...

}

Maven:

<dependency>

  <groupId>cloud.graal.gcn</groupId>

  <artifactId>gcn-bom</artifactId>

  <version>4.3.7.2</version>

  <type>pom</type>

  <scope>import</scope>

</dependency>

GDK 4.3.7 works with both Java 21 and Java 17. GDK modules offer out-of-the-box support for native compilation with Oracle GraalVM for JDK 21 and JDK 17 Native Image. GDK applications compiled ahead-of-time with GraalVM Native Image require far less memory and CPU to run at scale, start up to 100x faster, operate at peak performance immediately, and have a much smaller attack surface compared to their traditional JVM-based counterparts.

Guides for Serverless Functions

This release contains new guides to help you create, deploy and run Serverless Functions on OCI, AWS, and GCP. See guides for more information.

Tools for GDK

The latest release of the tools for GDK brings with it some great updates. Most notably a rename of the extensions that provide support for the Micronaut® framework, the release of the GDK Launcher for IntelliJ Idea, and VisualVM support for VS Code.

Source: oracle.com

Continue reading

Announcing Oracle GraalVM for JDK 21

Oracle is pleased to announce the availability of Oracle GraalVM for JDK 21. This release brings with it new Java 21 features, improvements in Native Image performance, simplified usage of embedded languages, and more.

Project Loom Virtual Threads

First previewed in JDK 19, Project Loom is no longer a preview feature in JDK 21. GraalVM for JDK 21 implements Loom’s virtual threads when running on the JVM and when using Native Image.

Native Image Performance

While executables generated by GraalVM Native Image may be best known for their quick startup time, metrics such as memory usage, peak throughput, and latency are also critically important. With Oracle GraalVM for JDK 21 we see ahead-of-time (AOT) compilation achieving superior results on all metrics when benchmarking the popular Spring PetClinic application. While some developers might expect that JIT compilation would always outperform AOT compilation, the throughput achieved by Native Image generated executables in GraalVM for JDK 21 provide competitive peak performance.

All the following Spring PetClinic benchmark results were obtained with a maximum heap size of 512MB. The two configurations compared below are: a native executable produced by Oracle GraalVM for JDK 21 optimized with profile guided optimization (PGO); the same application running on GraalVM Community Edition for JDK 21 using the C2 JIT compiler. Both configurations use the G1 garbage collector.

Startup (seconds): Native 97% faster

GraalVM (C2 JIT)	Oracle GraalVM Native Image (PGO+G1)
7.09	0.21

Memory Usage (RSS in MB): Native 38% lower

GraalVM (C2 JIT)	Oracle GraalVM Native Image (PGO+G1)
1029	641

99th Percentile Latency (ms): Native 28% lower

GraalVM (C2 JIT)	Oracle GraalVM Native Image (PGO+G1)
7.20	5.15

Throughput (requests/second): On par

GraalVM (C2 JIT)	Oracle GraalVM Native Image (PGO+G1)
11066	11902

With these latest results, we can see that Oracle GraalVM Native Image can provide faster startup time, reduced memory requirements, and lower latency while maintaining throughput making it an ideal choice for microservices, functions, and other workloads where minimizing operating cost is critical.

New Container Images

To support container-based application development and deployment, new container images are available for the Oracle GraalVM JDK and Native Image in the Oracle Container Repository. The `jdk` image can be used to deploy Java applications while the `native-image` container image includes all the tools required to compile applications into native executables.

Faster Compile Times

To reduce application compile times, some optimization phases that were previously included in the default level 2 (-O2) have been moved to a new level 3 (-O3). The level 3 optimizations work best with profile guided optimization, so they are automatically enabled when compiling with `--pgo`. The result is faster default compilation times with no significant impact on application performance. PGO continues to employ the same optimizations as in previous releases.

During development, where the focus is on functionality, not performance, developers can continue to use the “quick build” option (-Ob) to reduce compile times. This option disables most memory and performance optimizations so the resulting executables are not recommended for production deployments.

Source: oracle.com

Continue reading

Announcing Graal Cloud Native 4

We're excited to announce the general availability of Graal Cloud Native 4 based on the recently launched Micronaut® framework 4!

Graal Cloud Native (GCN) is an Oracle build of the open source Micronaut framework. GCN provides a curated set of Micronaut framework modules that simplify cloud application development, are designed to be compiled ahead-of-time with GraalVM Native Image, and are fully supported by Oracle. GCN enables you to easily build portable cloud native Java microservices that start instantly and use fewer resources to reduce compute costs.

What's new in GCN 4?

Let's look at some of the notable changes in this release.

GCN BOM 2.0

We have a new bill of materials (BOM) 2.0 consisting of specific versions of Micronaut framework 4 modules and their dependencies that are compatible and tested together. This reduces the risk of library incompatibility and version mismatches, and saves you from having to test and figure this out yourself.

Include the BOM in your build files using:

Gradle:

dependencies {

    micronautBoms(platform("cloud.graal.gcn:gcn-bom:2.0"))

    ...

}

Maven:

<dependency>

      <groupId>cloud.graal.gcn</groupId>

      <artifactId>gcn-bom</artifactId>

      <version>2.0</version>

      <type>pom</type>

      <scope>import</scope>

    </dependency>

Java 17

GCN 4 is designed and tested to work with Java 17 and later versions.

Gradle 8

If you use Gradle to build your GCN applications, Gradle 8 is the minimum version required to work with GCN 4.

Micronaut Serialization

Micronaut Serialization is a fully featured compile-time replacement for Jackson and is now the default in GCN and Micronaut framework 4. Micronaut Serialization provides reflection-free, fast and secure JSON serialization/deserialization APIs whilst maintaining API compatibility with Jackson annotations.

Shown below is an example of including Micronaut Serialization in your build files for GCN 4 vs GCN 3.8.5:

GCN 4 - Gradle:

dependencies {

    ...

    implementation("io.micronaut.serde:micronaut-serde-jackson")

    ...

}

GCN 3.8.5 - Gradle:

dependencies {

    ...

    implementation("io.micronaut:micronaut-jackson-databind")

    ...

}

GCN 4 - Maven:

<dependency>

      <groupId>io.micronaut.serde</groupId>

      <artifactId>micronaut-serde-jackson</artifactId>

      <scope>compile</scope>

    </dependency>

GCN 3.8.5 - Maven:

<dependency>

      <groupId>io.micronaut</groupId>

      <artifactId>micronaut-jackson-databind</artifactId>

      <scope>compile</scope>

    </dependency>

GraalVM Integration

GCN 4 modules have been designed and tested to work with the latest release of Oracle GraalVM for JDK 17 Native Image available under the GraalVM Free Terms and Conditions (GFTC) license.

The reachability metadata of GCN and Micronaut framework 4 modules and their dependencies is stored in the shared GraalVM Reachability Metadata repository and these modules have been listed on the Libraries and Frameworks Tested with Native Image page. GCN and Micronaut framework 4’s GraalVM integration has been reworked to use this shared metadata repository using the Micronaut Maven and Gradle plugins and GraalVM Native Build Tools. This makes it extremely simple for you to compile your GCN application into a native executable with GraalVM Native Image.

Application Configuration Files

Micronaut framework 4 no longer exposes SnakeYAML as a transitive dependency. So, by default, GCN 4 uses properties files instead of YAML files for application configuration. This reduces the attack surface of your applications by eliminating an external (SnakeYAML) library.

Shown below is an example of an application configuration file for GCN 4 vs GCN 3.8.5:

GCN 4 - Properties File:

micronaut.application.name=dbDemo

flyway.datasources.default.enabled=true

datasources.default.db-type=mysql

datasources.default.dialect=MYSQL

datasources.default.driver-class-name=com.mysql.cj.jdbc.Driver

GCN 3.8.5 - YAML File:

micronaut:

  application:

    name: dbDemo

flyway:

  datasources:

    default:

      enabled: true

datasources:

  default:

    db-type: mysql

    dialect: MYSQL

    driver-class-name: com.mysql.cj.jdbc.Driver

Javax to Jakarta Transition

Micronaut framework 4 has finished the Javax to Jakarta transition. So, GCN uses jakarta.validation instead of javax.validation, jakarta.mail instead of javax.mail, jakarta.transaction instead of javax.transaction, and so on.

Shown below are some examples of GCN 4 vs GCN 3.8.5:

GCN 4:

import jakarta.validation.Valid;

import jakarta.validation.constraints.Max;

import jakarta.validation.constraints.Min;

import jakarta.validation.constraints.NotBlank;

import jakarta.validation.constraints.NotNull;

import jakarta.transaction.Transactional;

GCN 3.8.5:

import javax.validation.Valid;

import javax.validation.constraints.Max;

import javax.validation.constraints.Min;

import javax.validation.constraints.NotBlank;

import javax.validation.constraints.NotNull;

import javax.transaction.Transactional;

Improved Modularity

Micronaut framework 4 is more modular enabling you to deploy even smaller microservices with reduced native executable and container image sizes, and faster startup. The built-in Validation, Retry, Service Discovery, HTTP Session and WebSocket features have been split into separate modules enabling you to remove this functionality if not needed.

Shown below is an example of using Micronaut Validation in your build files for GCN 4:

GCN 4 - Gradle:

  

annotationProcessor("io.micronaut.validation:micronaut-validation-processor")

implementation("io.micronaut.validation:micronaut-validation")

GCN 4 - Maven:

  

<annotationProcessorPaths>

    <path>

        <groupId>io.micronaut.validation</groupId>

        <artifactId>micronaut-validation-processor</artifactId>

    </path>

</annotationProcessorPaths>

...

 

...

<dependency>

    <groupId>io.micronaut.validation</groupId>

    <artifactId>micronaut-validation</artifactId>

</dependency>

Cloud Modules

GCN and Micronaut framework 4 contain cloud modules with improved support for Oracle Cloud. The Oracle Cloud SDK has been enhanced to be compatible with Micronaut Serialization improving the speed and security of requests and responses by eliminating the need for Jackson. The transport layer for the Oracle Cloud SDK has also been replaced with Netty, avoiding the need for a second HTTP client (Jersey) when writing applications, resulting in smaller container images and improved startup performance. You can also use the new Oracle Cloud Infrastructure Certificates service module to configure and manage HTTPS certificates with automatic refresh of expired certificates.

Object Storage adds Local Storage to ease local development and testing.

GCN Launcher and Guides

The GCN Launcher and Guides have been updated to include the above changes.

GCN VS Code Tooling

With this release, we have made several changes to the Visual Studio Code tooling for Graal Cloud Native.

The GCN VS Code Tools have their own home page, https://www.graal.cloud/gcn/vscode-tools/. Here, you can access the documentation, guides, and watch a video of the tooling in action.

We now support creating and working with Graal Cloud Native 4.0 and Micronaut 4.0 projects.

We've added a Bean and Endpoints explorer view for Micronaut, that also lets you run REST requests against endpoints from within the IDE.

We've added a CodeLens for 'Run in Continuous' mode. When you update a running Micronaut application launched from the CodeLens, the application is rebuilt and runs automatically, improving the overall developer experience.

Finally, we have released our database tooling that enables you to create Micronaut Data classes directly from an existing database schema (Oracle Autonomous Database). This feature makes it super easy to expose existing databases programmatically through GCN and Micronaut applications!

JSON Relational Duality Views

The latest version of Micronaut Data JDBC comes with support for Oracle Database 23c and JSON Relational Duality Views. JSON Relational Duality Views provides the benefits of both relational tables and JSON documents, without the trade-offs of either approach.

Other Changes

GCN 4 includes several other notable Micronaut framework 4 features including, Early support for Virtual Threads (Project Loom) with JDK 19 and later, Optimized Netty-based HTTP layer for Virtual Threads, Improved HTTP performance (up to 50% better throughput), experimental support for HTTP/3 and IO_Uring, and a new compile-time expression language (EL).

Source: oracle.com

Continue reading

Unleashing the Power of Oracle GraalVM for JDK 21

Introduction

In the ever-evolving landscape of Java Development, staying ahead of the curve is not just a choice; it's a necessity. The advent of JDK 21 brings forth a technological marvel, and we, at Oracle Java Certifed, are excited to guide you through the immense capabilities of Oracle GraalVM, propelling your Java applications to new heights.

Understanding Oracle GraalVM

What sets GraalVM Apart?

Oracle GraalVM, often hailed as the secret weapon for developers, is a high-performance runtime that supports various languages, including Java, JavaScript, Python, Ruby, and more. What distinguishes GraalVM is its ability to provide unmatched speed and efficiency, transcending the limitations of conventional Java Development Kits.

Key Features of Oracle GraalVM

1. Polyglot Programming: Embrace a polyglot approach, enabling seamless integration of multiple languages within the same application.

2. Ahead-of-Time Compilation (AOT): Boost your application's startup time and overall performance with GraalVM's AOT compilation, a game-changer for resource-intensive applications.

3. Native Image Support: Transform your Java applications into standalone executables with GraalVM's native image support, reducing memory footprint and enhancing deployment flexibility.

4. Extended Ecosystem Compatibility: GraalVM ensures compatibility with a vast ecosystem of libraries and frameworks, allowing developers to leverage existing tools effortlessly.

Harnessing the Power of JDK 21

Unveiling JDK 21 Features

Record Types Revolutionize Data Handling

In JDK 21, the introduction of record types signifies a paradigm shift in how developers handle data. With a concise syntax and automatic generation of methods like toString(), equals(), and hashCode(), record types enhance code readability and reduce boilerplate.

Pattern Matching for Switch Statements

JDK 21 introduces enhanced pattern matching for switch statements, simplifying code structures and making it more expressive. This feature streamlines the process of writing clear and concise code for complex scenarios.

Oracle GraalVM and JDK 21 Synergy

Performance Boost with Just-In-Time Compilation

The seamless integration of Oracle GraalVM with JDK 21 brings forth a synergy that developers dream of. The combination of GraalVM's Just-In-Time Compilation and JDK 21's powerful features results in unparalleled performance gains for your Java applications.

Polyglot Possibilities in Action

Imagine a scenario where your application seamlessly incorporates Java, JavaScript, and Python components. Oracle GraalVM, coupled with JDK 21, makes this a reality, opening the door to a world of polyglot possibilities that were once considered complex and challenging.

Implementation Best Practices

Incorporating Oracle GraalVM and JDK 21 in Your Project

1. Evaluate Compatibility: Before migration, assess the compatibility of your existing codebase with Oracle GraalVM and JDK 21 to ensure a smooth transition.

2. Optimize for Native Image: Leverage GraalVM's native image support by optimizing your application for better performance and reduced resource consumption.

3. Explore Polyglot Scenarios: Identify areas in your project where a polyglot approach could enhance functionality, and leverage GraalVM's capabilities accordingly.

Conclusion

In conclusion, Oracle GraalVM for JDK 21 is not just an upgrade; it's a leap into the future of Java development. The powerful features of JDK 21, coupled with the unmatched capabilities of Oracle GraalVM, position your applications for success in an increasingly competitive landscape.

Continue reading

Announcing GraalVM Enterprise in OCI Code Editor and Cloud Shell

Today, we are announcing that you can use GraalVM Enterprise directly in Oracle Cloud Infrastructure (OCI) Code Editor and Cloud Shell, at no additional cost. This means you can now edit and deploy high-performance Java, Spring Boot, and Micronaut application code from a browser, without any installation and configuration.

GraalVM is a high-performance JDK distribution that accelerates Java workloads. GraalVM Native Image ahead-of-time compilation builds your Java application into a native executable that is small, starts fast, and uses less memory and CPU. Leading Java microservices frameworks such as Spring Boot, Micronaut, Quarkus and Helidon support GraalVM Native Image.

Code Editor enables you to edit and deploy code directly from the Oracle Cloud Console. You can develop applications, service workflows, and scripts entirely from a browser. This makes it easy to rapidly prototype cloud solutions, try new services, and accomplish quick coding tasks.

Cloud Shell is a free-to-use browser-based terminal accessible from the Oracle Cloud Console. It provides access to a Linux shell with preinstalled developer tools and a pre-authenticated OCI CLI. You can use the shell to interact with OCI resources, follow labs and tutorials, and quickly run utility commands.

Using GraalVM Enterprise in Code Editor and Cloud Shell

GraalVM Enterprise JDK 17 and Native Image are now preinstalled in Cloud Shell, so you don’t have to install and configure a development machine. Code Editor's integration with Cloud Shell gives you direct access to GraalVM Enterprise JDK 17 and Native Image.

Simply login to the Oracle Cloud Console and launch Code Editor (or Cloud Shell). From the Code Editor (or Cloud Shell) terminal window, select GraalVM as your JDK by running the following command:

csruntimectl java set graalvmeejdk-17

Now you are all set to use GraalVM Enterprise JDK 17 and Native Image for your Java, Spring Boot, Micronaut, Helidon, and Quarkus applications. You can use the GraalVM Maven and Gradle plugins to build and package your application as a native executable or JAR file.

Source: oracle.com

Continue reading

Oracle NetSuite on GraalVM

Oracle has completely moved its integrated application suite of cloud business software, known as Oracle NetSuite (hereafter, “NetSuite”), to Oracle GraalVM for JDK 17. This recent migration has increased the overall performance of the application suite and reduced its consumption of resources. Keep reading to learn more about the migration, performance gains, and future plans.

The Technology Behind NetSuite

At its heart, NetSuite is a large-scale Java application that runs on more than 10,000 application servers worldwide. Each instance of the application consists of about 100,000 loaded Java classes.

Oracle achieved the seamless transition to Oracle GraalVM without any changes to the application's source code or modifications to its deployment configuration. There were no classpath changes and no dependency conflicts with the libraries used by the application.

Why Oracle GraalVM?

Oracle GraalVM measurably reduced the CPU time needed by NetSuite. Because it runs on tens of thousands of application servers, any reduction in CPU time has the potential to reduce the number of servers. It was simple to switch to the Graal JIT compiler by just replacing the existing JDK installation with no additional configuration.

Java Performance Results

The team tested the performance of NetSuite running with the Graal JIT and the performance with their existing JDK installation. Both were based on the same version of JDK: 17.0.6.

The results were divided into two categories based on the type of NetSuite server: Request Servers and Background Job Servers.

Using Graal JIT reduced the CPU time on both server types, achieving 1.08x speedup on average on the request serving servers (7.39% CPU time reduction) and 1.07x speedup on average on the background job processing servers (6.37% CPU time reduction). On some workloads, the average CPU time usage was reduced even by 13%, resulting in 1.15x speedup.

Executing JavaScript on the JVM

In addition to the acceleration GraalVM provides for Java, NetSuite also leverages Graal.js in its SuiteScript extension language. Built on JavaScript, SuiteScript enables complete customisation and automation of business processes. Using the SuiteScript APIs, core business records and user information can be accessed and manipulated via scripts that are executed at pre-defined events, such as field change or form submission. NetSuite chose Graal.js as their JavaScript runtime because of its support for the latest ECMAScript standards, the ease of migration from Rhino, and its outstanding performance. Graal.js is written using the GraalVM Truffle framework which enables compilation of guest language code (JavaScript in this case) into optimized machine code.

Conclusion and Future Plans

Compared to the previous installation, GraalVM reduced the CPU time consumed by the NetSuite application in the production environment by 6.4–7.4% on average with as much as 13% on some workloads. The transition to GraalVM was as simple as upgrading to the new GraalVM release.

The design of GraalVM enables maintenance as well as the addition of incremental improvements. Therefore, we expect NetSuite to achieve even better performance characteristics in the future thanks to new compiler optimizations and Truffle framework improvements.

Source: oracle.com

Continue reading

Announcing Graal Cloud Native

We're pleased to announce the general availability of Graal Cloud Native (GCN) v3.8.5.

GCN is a curated set of open source Micronaut® framework modules that simplify multicloud application development and are designed from the ground up to be compiled ahead-of-time with GraalVM Native Image. GCN enables you to easily build portable cloud native Java microservices that start instantly and use fewer resources to reduce compute costs.

Research shows that cloud native and multicloud are becoming more prevalent. As per Gartner and IDC, the majority of new applications will be cloud native by 2025. According to Oracle’s second annual multicloud survey results, multicloud is the new reality with 98% of enterprises surveyed already using or planning to use multicloud. Cost optimization, cloud vendor lock-in concerns, and workload portability are among the top motivators and challenges for multicloud.

Multicloud Portability

Today, building cloud native applications requires the use of cloud-proprietary APIs and libraries. As a result, cloud native applications are tied to the cloud platform and need to be rewritten to deploy and run on another cloud platform.

With GCN, you can write applications once and run them on any public cloud - Oracle Cloud Infrastructure (OCI), Amazon Web Services (AWS), Google Cloud Platform (GCP)*, and Azure*. GCN modules provide platform-independent libraries for a set of core public cloud services including object storage, secret management, streaming, logging, and more. GCN enables you to easily deploy and run the same application on multiple public clouds, and thus prevents cloud lock-in.

Faster and cheaper

Cost optimization is one of the biggest motivators for enterprises running applications in the cloud. GCN applications compiled by GraalVM Native Image start up to 100x faster, operate at peak performance immediately, and require less memory and CPU. As a result, GCN applications need fewer resources to run at scale, and help you meet your cost optimization goals.

Developer Productivity

You can reduce development time with out-of-the-box cloud service integrations and compile-time validation that detects errors at build time, not runtime. Micronaut improves Java developer productivity by detecting errors at compile time instead of runtime, and using annotations instead of runtime reflection.

GCN also provides tooling to make it easy to develop Micronaut applications in VS Code including auto-completion for code and configuration files. The tooling makes it easy to transition from local development to cloud-based development from within VS Code.

You can use the GCN Launcher to generate multicloud application starters to quickly get started with multicloud development.

Source: oracle.com

Continue reading

Announcing GraalVM Enterprise 22.3

The GraalVM 22.3 release delivers several new features including much anticipated support for Java 19 along with preview support for Project Loom virtual threads in both JVM JIT and Native Image ahead-of-time compiled applications. The release also includes compiler performance improvements, new monitoring and debugging features in Native Image, Python enhancements, and a new name for GraalPython!

Java 19

Java 19 support arrives in GraalVM 22.3 for Java and Native Image. Java 19 introduces language improvements from project Amber (Record Patterns and Pattern Matching for Switch), library enhancements to interoperate with non-Java Code (Foreign Function and Memory API), and the ability to leverage vector instructions (Vector API) from project Panama. It also adds preview support for Project Loom (Virtual Threads and Structured Concurrency).

Loom's virtual threads are a huge step forward for Java and can drastically reduce the effort required to write and maintain high-throughput, concurrent applications in Java. Now in GraalVM 22.3 for JDK 19 there's preview support for virtual threads. Native Image ahead-of-time compiled applications using vitual threads exhibit the same low resource requirements typically seen in native executables. This was demonstrated in a recent Devoxx conference session using a version of Conway's Game of Life that uses virtual threads with Native Image.

jlink

The JDK jlink utility generates a generates a custom runtime image that contains just the modules you need to run an application. Now in GraalVM 22.3 you can run jlink to generate a custom runtime image that uses the optimizing Graal JIT compiler for small high-performance application--these are ideal for use in containers when Native Image is not suitable.

Performance

GraalVM 22.3 introduces a new Graal JIT compiler optimization that uses a separate isolate for each compilation thread.  This change resulted in a significant 38% improvement in compilation speed on Renaissance, DeCapo, and Scala-DeCapo benchmarks.  This optimization is enabled by default and requires no configuration change.

Native Image

As GraalVM Native Image adoption continues to grow, additional developer tools and production monitoring and debugging support is needed. For monitoring, GraalVM 22.3 adds new JDK Flight Recorder (JFR) events (JavaMonitorEnter, JavaMonitorWait, and ThreadSleep) that build on the previous support for custom JFR events. JFR support will continue to be enhanced until it is on par with the JVM to ensure that ahead-of-time compiled applications enjoy the same level of support as JIT applications.

Performance analysis of native executables is improved with new support for the Linux perf command so that perf report prints Java method names in its output histogram. This means you can map native machine code performance issues to your original Java source. You can read more about using perf and valgrind in the GraalVM documentation.

GraalVM 22.3 provides initial support for jvmstat along with a new command line option to enable it. The -enable-monitoring=<all,heapdump,jfr,jvmstat> option provides fine-grained control over monitoring features included in native executables. The -H:+AllowVMInspection option is now deprecated.

Python

GraalVM support for Python has some big advances in the 22.3 release and also gets a name change. Starting with GraalVM 22.3, "GraalPython" is now "GraalPy". In accordance with this change, the launcher has been renamed to graalpy and symlinks from python and python3 are added to provide better integration with other tools.

GraalPy pip support is enhanced to automatically choose the best version for a known package. For example, "pip install pandas" selects the versions of pandas and numpy that have been tested with GraalPy. And with the addition of support for the sys.settrace API, you can now use GraalPy in PyCharm as the standard Python interpreter and with other standard tools.

GraalVM is known for its excellent performance and that applies to Python with a number of improvements in the 22.3 release including:

◉ A new bytecode-based interpreter that provides better startup performance and reduces memory footprint while retaining good JIT-compiled performance

◉ A 20-25% improvement in interpreter performance

◉ A 25% reduction in memory footprint in all benchmarks

◉ For developers on Apple silicon, GraalPy AArch64 binaries for Darwin and Linux are now available.

Source: oracle.com

Continue reading

Go Native with Spring Boot 3 and GraalVM

Introduction

There has been a lot of interest in the past few years about "native Java". You've probably read articles or seen conference talks on the subject.

TL;DR - "native Java"

Traditionally Java programs are compiled to bytecode. At runtime the bytecode is first interpreted and eventually compiled to native machine code by a JVM.

Native Java is the idea of using ahead-of-time (AOT) compilation to produce a native executable or "native image" for a Java application.

A native image can run standalone without relying on a JVM.

This approach potentially offers advantages in terms of:

◉ faster application startup

◉ lower latency

◉ lower memory and CPU footprint and cost

GraalVM is an open source JDK that can compile Java applications to native images, as well as bytecode in the traditional way.

Native Java and Spring

Spring is the most popular Java application framework used today.

Over the last three years, the Spring and GraalVM teams have been working to make it easier for developers to deliver their Spring applications as native images.

Experimental support for native image was achieved via the Spring Native project.

With Spring Boot 3 and Spring 6 (due to be released November 24, 2022), support for native image will be available as a core feature.

Since the release candidate for Spring Boot 3 is now available, this seems a good time to try out the native image support.

Trying it out

So lets have a go at using the Spring Boot 3 release candidate and GraalVM to create a simple web application, compiled to a native executable.

Pre - requisites

You need to have GraalVM and it's native-image tool installed on your machine.

You can download these from here.

Note that you need GraalVM 22.3.0 and the equivalent version of native-image.

I'm using GraalVM Enterprise and native-image 22.3.0

The Spring Boot App

The easiest way to get started with building a Spring Boot app is to use the spring initializr.

I'm going to walk through using both Maven and Gradle, so you can pick whichever one you pefer.

You can either enter the configuration by hand, or re use one of:

• Gradle configuration
• Maven configuration

After choosing the build engine, I selected:

• Spring Boot: 3.0.0 (RC1)
• Language: Java
• Artifact: Vanilla
• Dependencies:
• GraalVM Native Support
• Spring Web

Once you are happy with your configuration click the "GENERATE" button.

Then copy the downloaded file to a directory of your choice, unzip it and cd into the vanilla directory.

Gradle

Start by running the application:

./gradlew bootRun

The application should start in a second or so:

You can to test the application:

curl localhost:8080

404 isn't a good look, so let's add a RestController to say something more meaningful.

Copy Hello.java from the code directory into ./src/main/java/com/example/vanilla (or write your own).

If we run the application (./gradlew bootRun) and test it (curl localhost:8080) again we should see a more meaningful response this time:

We can also build a stand alone jar:

./gradlew assemble

And run that:

java -jar ./build/libs/vanilla-0.0.1-SNAPSHOT.jar

Again you should see the app start in about a second:

So now we can take the next step and build our native image without having to make any changes to the project:

./gradlew nativeCompile

This may be a good opportunity to have a tea or coffee as it will take two or three minutes as opposed to a couple of seconds for building a jar (on my Mac, YMMV).

Once the build completes:

We can run the executable:

./build/native/nativeCompile/vanilla

You should see the application start in around ~0.1 seconds (so about 10x faster).

Looking at memory usage on my machine, the native image uses about 1/3 of the memory compared to running the application from the jar.

Maven

Before you start, make sure that $JAVA_HOME is set to point to your GraalVM installation:

$ $JAVA_HOME/bin/java --version

java 17.0.5 2022-10-18 LTS

Java(TM) SE Runtime Environment GraalVM EE 22.3.0 (build 17.0.5+9-LTS-jvmci-22.3-b07)

Java HotSpot(TM) 64-Bit Server VM GraalVM EE 22.3.0 (build 17.0.5+9-LTS-jvmci-22.3-b07, mixed mode, sharing)

Then run the application:

./mvnw spring-boot:run

The application should start in a second or so:

You can use curl localhost:8080 to test the application:

404 isn't a good look, so let's add a RestController to say something more meaningful.

Copy Hello.java from the code directory into ./src/main/java/com/example/vanilla (or write your own).

If we run the application (./mvnw spring-boot:run) and test it (curl localhost:8080) again we should see a more meaningful response this time:

We can also build a stand alone jar:

/.mvnw package

And run that:

java -jar ./target/vanilla-0.0.1-SNAPSHOT.jar

Again you should see the app start in about a second.

So now we can take the next step and build our native image without having to make any changes to the project:

./mvnw -Pnative native:compile

This may be a good opportunity as it will take two or three minutes as opposed to a couple of seconds for building a jar (on my Mac, YMMV).

Once the build completes:

We can run the executable ./target/vanilla

You should see the application start in around ~0.1 seconds (so about 10x faster).

Looking at memory usage on my machine, the native image uses about 1/3 of the memory compared to running the application from the jar.

Source: oracle.com

Continue reading

TruffleRuby on OCI Container Instances

Elegance at Speed

Ruby is one of my favourite programming languages. I really appreciate how expressive it is, how productive (and how much fun) it makes development.

Unfortunately Ruby has a reputation for being slow compared to other languages such as JavaScript.

While the performance of the default Ruby interpreter has improved, it still hasn't had the engineering investment that goes into V8.

Continue reading