[proposal] Make registration of GraalVM compiler as a JVM JIT optional requirement.

[andrii0lomakin]

Currently, the GraalVM compiler is used to parse JVM byte code and create IR, which, after several transformations, is used to generate the final code for the targeted GPU/FPGA (and, I hope, in future NPU).

According to feedback from the Graal compiler team, such activity does not require registration of the Grall compiler as a JIT and can be done on the standalone instance.

Removing this mandatory requirement is the first step in greatly simplifying the installation process of TornadoVM. From conversations that I have conducted, there are serious doubts expressed by software developers about the usage of TornadoVM till this requirement (registration of JIT extension in JVM) is mandatory.

There is another use case when GraalVM as a JIT instance is used. It is the generation of optimized CPU code as a fallback in case it is impossible to run kernel on GPU.

It is proposed to change this fallback algorithm in the following way:

1. If there is a registered instance of the GraalVM compiler as a JIT, it will be used to generate optimized CPU code. (But only and only for this case). Since the JDK 23 GraalVM compiler is embedded in JVM and switched on by experimental option.
2. If there is no registered instance of the GraalVM compiler as JIT, JDK uses the default compiler to execute the byte code provided. Users will receive a warning with a suggestion to enable the GraalVM JIT compiler in such a case.

Implementation of this feature is the first step in providing TornadoVM as a simple Maven dependency. The other is to provide precompiled binaries in the form of jars for popular platforms, as JNA does.

[andrii0lomakin]

If there are no objections I will start working on this issue once I am done with #521 .

[jjfumero]

Hi @andrii0lomakin. Thanks for your interest. As we have discussed, we probably mean different things when we read/write this proposal. So please, go ahead. Looking forward to seeing this contribution.

From my view:

It is proposed to change this fallback algorithm in the following way:

1. If there is a registered instance of the GraalVM compiler as a JIT, it will be used to generate optimized CPU code. (But only and only for this case). Since the JDK 23 GraalVM compiler is embedded in JVM and switched on by experimental option.

This is how TornadoVM currently works when running in combination with GraalVM.

2. If there is no registered instance of the GraalVM compiler as JIT, JDK uses the default compiler to execute the byte code provided. Users will receive a warning with a suggestion to enable the GraalVM JIT compiler in such a case.

This is also how it currently works when TornadoVM is launched with any OpenJDK-based distribution.

[andrii0lomakin]

@jjfumero Thank you. Less work for me, then.
I will provide PR ASAP.

[andrii0lomakin]

Once this issue is completed, I plan to create and support presets of native builds for popular platforms. But let us see, no promises at the moment.