search

adinn / leydendoc

Creative Commons Zero v1.0 Universal
20 stars 2 forks source link

JDK-8223220 #1

Open TheShermanTanker opened 2 years ago

TheShermanTanker commented 2 years ago

Apologies if this isn't the right place for this, but I couldn't find any recent active discussion on Leyden

I was wondering if JEP draft "JDK-8223220: JVMCI based JIT Compiler pre-compiled as shared library" could be merged into Leyden? https://bugs.openjdk.java.net/browse/JDK-8223220

As of now it proposes to allow a JVMCI Compiler compiled with Graal's Native Image to be AOT Compiled and loaded as a shared library, something which I feel would be especially suited for Leyden rather than SubstrateVM. Aside from this I do also think adding an option to AOT compile code for the HotSpot VM to load (Not just for the JVMCI Compiler, but also for regular Java applications, similar to how the now defunct jaotc used to operate) instead of only compiling Java into standalone binaries would also provide substantial boosts for applications that do ultimately want the advantage of the JIT since the interpreter can be bypassed entirely with this approach, though it may ultimately be better to modify the existing javac compiler to support these alternative compilation pipelines through command line flags rather than adding an entirely new compiler to avoid requiring users to switch between different compilers. (Maybe native code can be compiled directly into the jar if users want native code to run on HotSpot instead of requiring it be loaded through flags as jaotc did?)

adinn commented 2 years ago

This is probably not the best place to have this discussion. However, in the absence of a project list I don't know of any other OpenJDK list that would be appropriate so I wil answer here.

Firstly, as far as I am aware, the ability to plug in the the Graal JVMCI JIT compiler as a shared library (generated by GraalVM Native) was actually realized somewhere back in jdk13/14.

That said, I am not sure how appropriate the option to use the Graal JIT in this way is for Leyden. The Leyden project is primarily intended to deliver a static Java specification and an update to the TCK. It may possibly also deliver a reference implementation but that has not yet been decided.

The question that really needs to be asked here is whether use of the Graal JIT is appropriate for this reference implementation. That question can be asked independently of whether it is plugged in as a Java library or a native compiled shared library.

Up to now Red Hat has been looking at using only Hotspot components to provide an implementation of a static (aka native) image generator, specifically using the C2 compiler. The generated image is also envisaged as relying on (i.e. being linked to) some subset of the Hotspot JVM libraries, the latter used to implement the required virtual machine and native method functions. Although Red Hat was interested in adopting some of the same design principles as GraalVM Native we decided explicitly not to use the Graal JIT and Substrate VM, nor to try to replicate their behaviour. This investigation was seen as useful solely because it would work towards providing a reference implementation that exists independent of Graal.

The alternative to this Hotspot-only route would probably not be to plug the Graal JIT into OpenJDK and modify it to generate code for a closed world app that will rely on the Hotspot JVM. If we go down the path of relying the Graal JIT then that is much more likely to be because we will adopt the GraalVM Native image generator and SubstrateVM as the reference implementation for static Java.

No decision has yet been made regarding either of these options.

TheShermanTanker commented 2 years ago

I do understand the decision to not utilize Graal's JIT Compiler (And in fact I also agree that Graal shouldn't directly be used within Leyden), but I believe there has been a misunderstanding, admittedly due to miscommunication on my part; I was not proposing modifying HotSpot to use either SubstrateVM or Graal JIT to compile native binaries, but rather more generally the possibility of using Leyden's pipeline in the future to compile any JVMCI Compiler written in Java to native code that HotSpot can then use. Said compiler doesn't have to be the Graal JIT, instead I was more concerned with whether what JDK-8223220 proposes could be more effectively achieved by Leyden with better results, since, as you said, it only specifically allows the Graal JIT compiled with SVM as a shared library, as opposed to any JVMCI compiler, which is a huge feature I forsee Leyden potentially having.

Graal and SubstrateVM aside, I was also wondering if there were any plans to allow Leyden to not just build native binaries, but also generate and bundle native code into otherwise regular jars that runs on the HotSpot VM (Perhaps through a javac flag?), similar to what jaotc from Metropolis attempted to achieve. This would effectively bypass HotSpot's Interpreter and allow it to immediately run and profile code generated by Leyden the moment an application is launched, which would conceivably improve startup times in my mind (I'm not sure if native code can be profiled as easily as Java bytecode however)

I guess I'll possibly continue this discussion in the future though, when Leyden's project and mailing lists are properly set up, since this is indeed not a great place to talk about it.

Have a great day ahead! :)