openj9 | Eclipse OpenJ9 : A Java Virtual Machine | Runtime Evironment library

Hotspot and OpenJ9 will compile to assembly, the assembly code being assembly for the platform you are running them on, as your program is running, or beforehand. It will compile from class files to the native code on that platform.

Since you cannot run Hotspot or J9 on Android, you cannot compile for Android this way.

For Android, you use the Android ART compiler, which compiles in a multi-step process from class files to dex files and apk files outside the device, then on the Android device to native code.

-XX:+PrintCompilation is an option of the HotSpot JVM. You are using OpenJ9 VM though.

To log JIT compilation in OpenJ9, use -Xjit:verbose

You don't need any variables set up. The link you provided has the answer. When you click the + button use the path that you've posted here /Users/jetfire/.jenv/versions/ibm64-15.0.1

I'm using sdkman so it's basically the same

There is no effect of using -XX:+UseG1GC on IBM JVM. It will just be silently swallowed. The JVM will default to Gencon GC policy.

You can verify that by running -verbose:gc, what will reported GC policy being used.

The closest IBM's GC policy to Hotspot's G1GC is Balanced one, the main distinguishing characteristics being they are region based (unlike Gencon that has two distinct ares of heap for old and new objects).

As far as concurrency, all 3 (G1GC, Balanced, Gencon) are similar: global GCs are mostly concurrent and partial/local GCs are STW (Stop-The-World).

Reasons to use region based GC policy are to reduce worst case pause time. They are capable of doing some global type operations incrementally in partial GCs. Most notably, they can incrementally de-fragment heap, unlike Gencon, that it does in global GC via optional STW compact operation. Most of applications will not require such global compact, hence Gencon is default. But, if long pauses due to global compaction are observed in Gencon run, Balanced should be tried. Balanced GC will however slightly compromise the application throughput.

Reading the armv8 spec:

The Floating-point move (register) instructions copy a scalar floating-point value from one register to another register without performing any conversion. Some of the Floating-point move (register) instructions overlap with the functionality provided by the Advanced SIMD instructions DUP , INS , and UMOV . However, Arm recommends using the FMOV instructions when operating on scalar floating-point data to avoid the creation of scalar floating-point code that depends on the availability of the Advanced SIMD instruction set. Table C3-64 shows the Floating-point move (register) instructions.

The spec suggests that this instruction is the only way to move from a floating point register to a general purpose register, if the listed SIMD instructions aren't available. So you need java code that converts a float to an int without performing a conversion, and a processor that doesn't have SIMD support.

The defacto way to do this in java seems to be Float.floatToIntBits.

On my JVM install(hotspot jdk8u forest) this is implemented as a native function. This native function eventually reaches hotspot/src/share/vm/opto/library_call.cpp, with the following code:

As pointed put by Nicoll, With Spring Cloud Vault 3.0 and Spring Boot 2.4, the bootstrap context initialization (bootstrap.yml, bootstrap.properties) of property sources was deprecated. This can be fixed in one of the 2 ways

1. Use Spring Boot 2.4.0 Config Data API to import configuration from Vault
2. Enable the bootstrap context either by setting the configuration property spring.cloud.bootstrap.enabled=true or by including the dependency org.springframework.cloud:spring-cloud-starter-bootstrap

1. Use Spring Boot 2.4.0 Config Data API

Move bootstrap.yml configuration to application.yml and define spring.config.import to import all profiles. And it looks like below

Java being Big Endian how does it handle Little Endian CPUs while maintaining performance?

Java is not Big Endian. In the few places in the Java Runtime Library where Endianness is even an issue, the API uses Big Endian, but it is always well-documented, and some of the APIs allow you to specify the Endianness you want.

Does JVM (OpenJDK, OpenJ9, etc.) do any special optimisations to maintain performance like only selectively being Big Endian in special situation in Little Endian platforms?

No, the JVM uses the native Endianness.

Is there special endianess handling when accessing ByteBuffers or calling native code or writing to IO or accessing volatile variables?

Yes, No, Yes, and No.

Since the JVM uses native byte order, there is no handling needed for calling native code or accessing volatile variables. Byte order only matters when (de)serializing to/from bytes, e.g. when accessing ByteBuffers or writing to IO.

How does Java change the endianess in Little Endian architectures?

Same way you would change Endianness anywhere, it swaps the bytes, or read/writes the bytes in the appropriate order.

At what point or operation (load, store, calculation, registers, cache, memory, etc.) is the endianess changed?

It's not, since the JVM uses the native Endianness. Endianness is only applied when the native value is converted to/from bytes. At no other point in time does Endianness matter.

What kind of performance penalty would this have?

None, since it doesn't do anything.

As of JProfiler 11.0, attach mode is not supported for OpenJ9 JVMs. Also, attach mode is not enabled by default for OpenJ9.

When passing the -agentpath VM parameter as given by the integration wizards, profiling OpenJ9 JVMs is fully supported.

Bottom line up front

The following Bash command sends both stdout and stderr from javac to both the screen and the file mk.out: