View on GitHub

SapMachine

Fast. Reliable. Open.

Features of SapMachine

SapMachine is kept as close as possible to the OpenJDK to make it usable as a drop-in replacement for any OpenJDK build by any vendor. Therefore, features and fixes identified to be required for SAP applications will usually be developed in and contributed to the OpenJDK.

It might happen that something which we deem important for our enterprise customers can not make its way into the OpenJDK. In that case we will accept differences between SapMachine and OpenJDK. But we try to be very cautious and selective with that.

To ensure transparency, this page outlines all SapMachine features that differ from upstream OpenJDK.

Version numbers

You can identify SapMachine using the java -version command (see below). Although the version information of SapMachine and OpenJDK/Oracle JDK are slightly different, the SapMachine version output still fully conforms to the format specified in the JEP 322: Time-Based Release Versioning and JEP 223: New Version-String Scheme. SapMachine follows the same version numbering scheme as OpenJDK.

SapMachine version information

$ ./sapmachine-25/bin/java -version
openjdk version "25.0.1" 2025-10-21 LTS
OpenJDK Runtime Environment SapMachine (build 25.0.1+8-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 25.0.1+8-LTS, mixed mode, sharing)

In addition to the original OpenJDK version output (see below), SapMachine adds an optional part (i.e. LTS) to the version number. This optional part (defined as optional build information in JEP 322) starts with LTS for long term support releases. If we will do an additional SapMachine specific release for this version, the fifth element of the version number will be increased and looks as follows 17.0.3.0.1+0-LTS. Once we pull and merge the next upstream release, this number will be reset to zero (e.g. 17.0.4+0-LTS). We are currently not using the build number part of the version string and always set it to 0.

The version date, as defined in JEP 322, will be set to the date, the SapMachine is generally available (GA). This date is never before the OpenJDK GA but may be set to a date after the OpenJDK GA.

OpenJDK version information

$ ./jdk-25-openjdk/bin/java -version
openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8)
OpenJDK 64-Bit Server VM (build 25.0.1+8, mixed mode, sharing)

System properties

The following differences in Java system properties exist between SapMachine and OpenJDK:

-    java.runtime.version = 25.0.1+8
+    java.runtime.version = 25.0.1+8-LTS
-    java.vendor = Oracle Corporation
-    java.vendor.url = https://java.oracle.com/
-    java.vendor.url.bug = https://bugreport.java.com/bugreport/
+    java.vendor = SAP SE
+    java.vendor.url = https://sapmachine.io/
+    java.vendor.url.bug = https://github.com/SAP/SapMachine/issues/new
+    java.vendor.version = SapMachine
-    java.vm.vendor = Oracle Corporation
-    java.vm.version = 25.0.1+8
+    java.vm.vendor = SAP SE
+    java.vm.version = 25.0.1+8-LTS

Behavioral differences

  • SapMachine enables extended thread dumps -XX:+PrintExtendedThreadInfo. See also JDK-8200720.

  • SapMachine enables output of additional information in exception messages by setting jdk.includeInExceptions in the java security configuration file. SapMachine 11 sets this property to ‘hostinfo’, SapMachine 12 and later set ‘hostinfo,jar’. See also JDK-8204622 and JDK-8207768.

  • SapMachine enables output of code snippets in exception messages.

  • SapMachine enables -XX:+ExtensiveErrorReports.

  • SapMachine trusts the SAP specific root certificate “SAP Global Root CA”, used by the SAP Global PKI infrastructure.

  • SapMachine has a supportability feature called Vitals.

  • SapMachine prints all flags in hs_err files, not just the default ones. Comments are omitted, though.

  • SapMachine enables JEP 519: Compact Object Headers per default since SapMachine 25 and beyond.

  • SapMachine enables -XX:+UseTransparentHugePages per default since SapMachine 25.0.2 and beyond. For earlier versions of SapMachine, specifically SapMachine 17 and 21, we recommend setting the -XX:+UseTransparentHugePages switch explicitly. The switch has been introduced exclusively for Linux platforms.

  • SapMachine introduces -XX:GlibcMallocArenas and optimizes Linux memory management in releases from 2026 onwards, reducing memory footprint and addressing reported performance issues. The switch has been introduced exclusively for Linux (glibc) platforms. It regulates the number of malloc arenas used by the JVM:
    • -XX:GlibcMallocArenas=0 Uses the OS default (typically eight times the number of CPUs).
    • -XX:GlibcMallocArenas=1 Uses one malloc arena (recommended).
    • -XX:GlibcMallocArenas=2 Allows up to two malloc arenas.
    • -XX:GlibcMallocArenas=<value> Allows up to <value> malloc arenas, where <value> is an integer.

    In SapMachine 25.0.2 and later, the default is set to 1, optimizing memory usage. Since SapMachine 21.0.10 and 17.0.18 onwards, the default remains 0 only for compatibility. For more insights, visit GitHub.

  • SapMachine reduced the number of CDS archives (*.jsa files shipped with SapMachine) in SapMachine 25 from 4 to 1 and this way reduced the size of the downloaded JDK image of SapMachine significantly. The jsa files contain preloaded JVM data to speed up the VM start by avoiding the need for some initialization operations. More information about CDS, including some info about application specific CDS can be found here: docs.oracle.com.

  • SapMachine has two additional JFR configurations, especially for GC profiling (gc.jfc and gc_details.jfc).

  • SapMachine handles some *OnOutOfMemoryErrorswitches differently than stock OpenJDK to be more useful in cloud scenarios. Behaviorial changes highlighted with italics:

    • ExitOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property -Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • prints “Terminating due to java.lang.OutOfMemoryError” to stdout
      • Exits the VM
    • CrashOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property -Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • writes an error report (hs_err_pid..)
      • prints “Aborting due to java.lang.OutOfMemoryError” to stdout
      • exits the VM
      • will NOT write a core file unless +CreateCoredumpOnCrash was explicitly specified on the command line
    • HeapDumpOnOutOfMemoryError
      • also works for thread exhaustion OOMs
      • also works for direct memory OOMs with system property -Djdk.nio.reportErrorOnDirectMemoryOom=true. Since 17.0.15/21.0.7
      • prints stack to stdout
      • generates heap dump
    • OnOutOfMemoryError=command
      • also works for thread exhaustion OOMs (but note that whatever resource exhaustion caused thread creation errors may cause the subsequent fork for command to fail as well)
      • prints stack to stdout
      • invokes the given command

    Notes:

    • Avoiding core file creation with CrashOnOutOfMemoryError is intentional. CrashOnOutOfMemoryError is by default tuned to shut the VM down with a minimum of fuzz while still giving us a useful error report. If a core file is wanted for post analysis, specify -XX:+CreateCoreDumpOnCrash.
    • For thread creation errors, xxxOnOutOfMemoryError switches are handled before the JVMTI ResourceExhausted event is posted. This means that JVMTI agents monitoring this event (e.g. CloundFoundry’s jvmkill) may not get invoked. This is intentional.
    • The SapMachine-specific flag ExitVMOnOutOfMemoryError (note the “VM” in the name, not to be confused with ExitOnOutOfMemoryError) is an alias to CrashOnOutOfMemoryError and provided for backward compatibility reasons.

Additionally Included Software

SapMachine includes async-profiler in the binary distribution.