paketo-buildpacks / graalvm

A Cloud Native Buildpack that provides the GraalVM implementations of JREs and JDKs

gcr.io/paketo-buildpacks/graalvm

The Paketo Buildpack for GraalVM is a Cloud Native Buildpack that provides the GraalVM implementations of the JDK and GraalVM Native Image builder.

This buildpack is designed to work in collaboration with other buildpacks which request contributions of JREs, JDKs, or Native Image builder.

Upstream releases

The Paketo team will do its best to provide the latest GraalVM implementations of the JDK and GraalVM, whenever they become available, according to this schedule: https://www.graalvm.org/release-notes/release-calendar/#planned-releases

Behavior

This buildpack will participate if any of the following conditions are met

• Another buildpack requires jdk
• Another buildpack requires jre
• Another buildpack requires native-image-builder

The buildpack will do the following if a JDK is requested:

• Contributes a JDK to a layer marked build and cache with all commands on $PATH
• Contributes $JAVA_HOME configured to the build layer
• Contributes $JDK_HOME configure to the build layer

The buildpack will do the following if native-image-builder is requested:

• Contribute a JDK (see above)
• Installs the Native Image Substrate VM into the JDK
• Prevents the JRE from being installed, even if requested

The buildpack will do the following if a JRE is requested:

• Contributes a JDK to a layer with all commands on $PATH (GraalVM does not distribute a standalone JRE)
• Contributes $JAVA_HOME configured to the layer
• Contributes -XX:ActiveProcessorCount to the layer
• Contributes -XX:+ExitOnOutOfMemoryError to the layer
• Contributes -XX:+UnlockDiagnosticVMOptions,-XX:NativeMemoryTracking=summary & -XX:+PrintNMTStatistics to the layer (Java NMT)
• If BPL_JMX_ENABLED = true
  • Contributes -Djava.rmi.server.hostname=127.0.0.1, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false & -Dcom.sun.management.jmxremote.rmi.port=5000
• If BPL_DEBUG_ENABLED = true
  • Contributes -agentlib:jdwp=transport=dt_socket,server=y,address=*:8000,suspend=n.
• If BPL_JFR_ENABLED = true
  • Contributes -XX:StartFlightRecording=dumponexit=true,filename=/tmp/recording.jfr
• Contributes $MALLOC_ARENA_MAX to the layer
• Disables JVM DNS caching if link-local DNS is available
• If metadata.build = true
  • Marks layer as build and cache
• If metadata.launch = true
  • Marks layer as launch
• Contributes Memory Calculator to a layer marked launch
• Contributes Heap Dump helper to a layer marked launch

Configuration

Environment Variable	Description
$BP_JVM_VERSION	Configure a specific JVM version (e.g. 17, 21). The buildpack will download JDK and Native Image Substrate VM assets that are compatible with this version of the JVM specification. Since the buildpack only ships a single version of each supported line, updates to the buildpack can change the exact version of the JDK or JRE. In order to hold the JDK and JRE versions stable, the buildpack version itself must be stable. Buildpack releases (and the dependency versions for each release) can be found here. Few users will use this buildpack directly, instead consuming a language buildpack like paketo-buildpacks/java who's releases (and the individual buildpack versions and dependency versions for each release) can be found here. Finally, some users will will consume builders like paketobuildpacks/builder:base who's releases can be found here. To determine the individual buildpack versions and dependency versions for each builder release use the pack inspect-builder <image> functionality.
$BPL_JVM_HEAD_ROOM	Configure the percentage of headroom the memory calculator will allocated. Defaults to 0.
$BPL_JVM_LOADED_CLASS_COUNT	Configure the number of classes that will be loaded at runtime. Defaults to 35% of the number of classes.
$BPL_JVM_THREAD_COUNT	Configure the number of user threads at runtime. Defaults to 250.
$BPL_JVM_CLASS_ADJUSTMENT	Absolute or percentage based adjustment of the memory calculator's class count, which influences various memory settings of the JVM. This is useful when the number of classes cannot be reliably determined during build-time and workloads run into OOM situations. Defaults to 100%.
$BPL_JAVA_NMT_ENABLED	Configure whether Java Native Memory Tracking (NMT) is enabled. Defaults to true. Set this to false to disable NMT functionality.
$BPL_JAVA_NMT_LEVEL	Configure the level of detail for Java Native Memory Tracking (NMT) output. Defaults to summary. Set this to detail for detailed NMT output.
$BPL_JMX_ENABLED	Configure whether Java Management Extensions (JMX) is enabled. Defaults to false. Set this to true to enable JMX functionality.
$BPL_JMX_PORT	Configure the port number for JMX. Defaults to 5000. When running the container, this value should match the port published locally, i.e. for Docker: --publish 5000:5000
$BPL_DEBUG_ENABLED	Configure whether remote debugging features are enabled. Defaults to false. Set this to true to enable remote debugging.
$BPL_DEBUG_PORT	Configure the port number for remote debugging. Defaults to 8000.
$BPL_DEBUG_SUSPEND	Configure whether to suspend execution until a debugger has attached. Defaults to false.
$BPL_JFR_ENABLED	Configure whether Java Flight Recording (JFR) is enabled. If no arguments are specified via BPL_JFR_ARGS, the default config args dumponexit=true,filename=/tmp/recording.jfr are added.
$BPL_JFR_ARGS	Configure custom arguments to Java Flight Recording, via a comma-separated list, e.g. duration=10s,maxage=1m. If any values are specified, no default args are supplied.
$BP_JVM_JLINK_ENABLED	Configures whether to run the JDK's jlink tool at build time to generate a custom JRE. Defaults to false. If no custom args are specified, the default args are --no-man-pages --no-header-files --strip-debug --compress=1.
$BP_JVM_JLINK_ARGS	Configure custom arguments to supply to the jlink tool. If any custom args are specified, no default args are supplied.
$BPL_HEAP_DUMP_PATH	Configure the location for writing heap dumps in the event of an OutOfMemoryError exception. Defaults to ``, which disables writing heap dumps. The path set must be writable by the JVM process.
$JAVA_TOOL_OPTIONS	Configure the JVM launch flags

Bindings

The buildpack optionally accepts the following bindings:

Type: dependency-mapping

Key	Value	Description
<dependency-digest>	<uri>	If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

License

This buildpack is released under version 2.0 of the Apache License.

graalvm's Issues

How to use different GraalVM version(aarch64)?

Hi,

I'm using Spring Native and was wondering if there's some way to pointing to a different GraalVM version(aarch64).

Pom.xml

<plugin>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-maven-plugin</artifactId>
	<configuration>
		<image>
			<builder>paketobuildpacks/builder:tiny</builder>
			<env>
				<BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
			</env>
		</image>
	</configuration>
</plugin>

Documentation should reflect $JAVA_OPTS being an input

Currently, the buildpack takes ${JAVA_OPTS} as an input, however the documentation and the buildpack configuration metadata does not mention it. These things should be updated to reflect reality.

[spring-projects/spring-boot#21582]

不支持mac os环境吗？

我的开发环境是mac os ,当运行：

./mvnw -Dmaven.test.skip=true spring-boot:build-image

红色方框内应该为“graalvm-ce-java11-darwin-amd64-21.2.0.tar.gz”。

How to download GraalVM faster?

Description

When start build spring-native image by Maven, the process will wait for downloading GrallVM for a very long time.
Maybe it's a network problem, but i want to know is there any other ways to speedup this step.

Maven Config

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <builder>paketobuildpacks/builder:tiny</builder>
      <env>
        <BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
      </env>
    </image>
  </configuration>
</plugin>

Build Cmd

mvn spring-boot:build-image

Docker Builder Container Logs

===> DETECTING

4 of 11 buildpacks participating

paketo-buildpacks/graalvm 6.0.0

paketo-buildpacks/executable-jar 5.0.0

paketo-buildpacks/spring-boot 4.2.0

paketo-buildpacks/native-image 4.0.0

===> ANALYZING

Previous image with name "docker.io/library/spring-native-build-docker-demo:0.0.1-SNAPSHOT" not found

===> RESTORING

===> BUILDING



Paketo GraalVM Buildpack 6.0.0

https://github.com/paketo-buildpacks/graalvm

Build Configuration:

$BP_JVM_VERSION 8.* the Java version

Launch Configuration:

$BPL_JVM_HEAD_ROOM 0 the headroom in memory calculation

$BPL_JVM_LOADED_CLASS_COUNT 35% of classes the number of loaded classes in memory calculation

$BPL_JVM_THREAD_COUNT 250 the number of threads in memory calculation

$JAVA_TOOL_OPTIONS the JVM launch flags

GraalVM JDK 8.0.282: Contributing to layer

Downloading from https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-21.0.0.2/graalvm-ce-java8-linux-amd64-21.0.0.2.tar.gz

Support CA Certificates with native images

When configuring a JDK or JRE, this buildpack will add any certificates provided by the CA Certificates buildpack to the JVM truststore. It does not appear that certificates provided by CA Certificates will be configured correctly when building a native image. Can support for CA Certificates in native images be added?

Allow `gu install` of other items

Right now when the GraalVM buildpack runs, it installs GraalVM and then can optionally install the Native image substrate VM. It uses the gu tool to install the native image tools.

GraalVM has other items that it can gu install, such as support for alternative languages like Python or Javascript. These don't work at the moment because they are additional items that must be installed and the buildpack does not provide a way to install them at the moment.

This is an enhancement request to allow other tools to be gu installed.

The use case is for running things like Python ML code through the JVM, which can be faster.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Oracle GraalVM version?

Hi there,

I want to use the Enterprise version with the buildpack to use PGO a G1 GC, but it seems there's no way to do that with the buildpack, which pretty much ruins the build pipeline I've set up for our product. Is there any way or any plans to be able to do this?

Will Java 16 be supported?

Since GraalVM supports Java 16 (https://www.graalvm.org/release-notes/21_1/), just wondering will the buildpack support Java 16 too?

Support Static / `FROM scratch`

It'd be great if there was a way for this buildpack to support static native images so that the run image can be scratch.

Bonus points if the created native application can optionally be packed with upx.

Here is an example Dockerfile that does all this:
https://github.com/jamesward/comparing-docker-methods/blob/graalvm/Dockerfile

Environment Variable/Flag for Running GraalVM Tracing Agent

Describe the Enhancement

It would be great if I can deploy apps in their target environment with the native image tracing agent enabled, so that I can execute all code paths and capture all of the metadata needed for the subsequent native compilation. I know I can probably pass the arg myself, but I'm also looking for confirmation that the agent will be available in this JVM/JDK.

support for java20

can you please tell the estimated time by which we will get the support for graalvm20

Support for Java 21

I know it's just been a week since java 21 released, but I would like to ask if there is already a rough ETA on support for graalvm21 native image?

Thanks in advance.

Investigate new GraalVM included native-image

Describe the Enhancement

GraalVM team recently announced a new release model, that will include native-image directly in the future GraalVM archives. https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5
It would be nice to evaluate the impact it could have on the graalvm buildpack.

Possible Solution

It should be possible to simplify the code and no longer rely on gu install; see https://github.com/paketo-buildpacks/graalvm/blob/main/cmd/main/main.go#L39 for example
@pivotal-david-osullivan mentioned:

I think it will at least involve swapping the BundledWithJDK flag in GraalVM’s main to true and removing the other properties there that point to gu

Motivation

Adapt to new packaging, simplify the codebase

Native image to be bundled

Coming soon, native image will be bundled with the GraalVM JDK. No more need to gu install it.

oracle/graal#5995

Current Behavior

Currently the buildpack gu installs native image.

Possible Solution

We'll need some sort of check to make sure that installation only happens when necessary. Possibly by version, but we might also be able to just check for it and see if it exists. If so, then don't install it.

Motivations

GraalVM and native image builds should continue to seamlessly work regardless of version.