[External] : Re: Call for Discussion: New Project: Galahad
Douglas Simon
doug.simon at oracle.com
Wed Dec 21 18:16:14 UTC 2022
Hi Julian,
Thanks for raising these questions. Here’s my take.
A goal of Galahad is to move development of Graal into OpenJDK and subsequently propose patches for main-line. Upon successful inclusion, it should not impose any extra maintenance costs.
In terms of concerns about underutilization, I don’t believe it makes sense to integrate Graal into a JDK main-line repo until it at least matches the existing JIT compilers on a number of metrics, including memory footprint, warmup time and compilation speed. Only once it has these characteristics will it be interesting as an alternative or even replacement for an existing JIT compiler.
-Doug
On 21 Dec 2022, at 13:11, Julian Waters <tanksherman27 at gmail.com> wrote:
Hi, just a couple of quick questions, if you don't mind
"The initial focus will be on contributing the latest version of the GraalVM just-in-time (JIT) compiler and integrating it as an alternative to the existing JIT compiler of the HotSpot VM. Later steps will bring in the necessary ahead-of-time (AOT) compilation technology to make this new JIT compiler written in Java available instantly on JVM start and avoid any interference with application heap usage and execution profiling."
Isn't this what the now inactive Metropolis project aimed to achieve with Graal as well? It even managed to make substantial progress in having the Graal compiler available as an alternative JIT, but it was ultimately removed from the JDK some time ago, due to high maintenance costs (https://openjdk.org/jeps/410). To my knowledge Metropolis hasn't been abandoned yet, so wouldn't this project's goals conflict slightly with it? Also somewhat concerning is the reason for the previous removal, what's not to say that developers will again under-utilize the Graal runtime compiler this time?
"We also intend to contribute portions of the Native Image technology as a general AOT compilation technology for Java applications"
Pretty interesting to think about, but given Leyden's leaning towards enhancing C2 to compile AOT images, would the multiple available AOT technologies prove confusing to choose between?
I am glad that compiling the JIT itself ahead of time is also something being considered though, because that's all the more reason to talk about compiling AOT code meant to run on HotSpot itself in Leyden, instead of just closed world images ;)
best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20221221/2052de04/attachment.htm>
More information about the discuss
mailing list