Introduction of Alhambra project

[Irina Arkhipets]

Hi Roman,

Thank you for the provided info!

It sounds interesting to make the JIT using Graal front-end and LLVM. Now
we are at the beginning of the road, so currently our progress is based on
the Java 8 with LLVM support since it is the most used in production. Graal
looks really interesting, but it is not quite clear if/when it will make
its way to standard SDK and will it ever be accepted as default JRE.
We will definitely take your comments into consideration and it would be
great if you participate in the project in any role.

Best regards,
Irina

On Tue, Jul 14, 2020 at 11:37 PM Roman Kennke <rkennke at redhat.com> wrote:

> Hi Irina,
>
>
> > Our particular interest is in finding most efficient ways of porting
> > latest
> > OpenJDK to new platforms, we assume it should be possible to port
> > optimizing JIT compiler without introducing lots of platform specific
> > helpers and custom codegens. Of course we're aware of Zero/Shark
> > project
> > experience, initially we considered to restore it and even
> > implemented it
> > for Java 8. After some experiments and performance analysis, we
> > believe
> > that a better solution would be to combine the Opto JIT front-end and
> > its
> > elaborated Java-specific platform-independent optimizations with
> > power of
> > modern LLVM back-end. Therefore, we propose the Alhambra project to
> > develop
> > such a  JIT compiler.
> >
>
> I was one of the maintainers of Shark for a while, and I was also the
> one who eventually removed it from the source tree (JDK9 time frame,
> iirc).
>
> I still find this a very interesting project, and maybe the most
> pressing limitations in LLVM and OpenJDK have since been solved:
>
> 1. We now have JVMCI, the compiler interface that is used by Graal, and
> which seems like the obvious choice to also implement new JIT like the
> one you are proposing. There seems no need to directly interface with
> C2/opto compiler like Shark did.
> 2. The major problem with Shark was the lack of support for GC in LLVM
> back then (in particular, how GC can access and manage references on
> the stack). I've heard that this has immensely improved since then.
> 3. I am not sure what the status of JIT support in LLVM is. Might be
> worth to investigate. Back in the day, Shark used the 'regular' LLVM
> compiler, because JIT support was basically limited to x86. Maybe this
> has improved since then.
> 4. Also, the APIs of LLVM tended to evolve very rapidly, and it was
> difficult to keep up with it, and especially figuring out the correct
> version of LLVM to work with Shark was a nightmare. At some point we
> littered Shark with #ifdefs to figure out the LLVM version to compile
> against, and use the correct APIs for that. I hope that the situation
> is better now.
>
>
> > We are going to base it on OpenJDK 11 since it's a recent stable LTS
> > version, however I am not quite sure that it's still open for the new
> > features.
>
> If I were you, I'd base it on the development branch that is currently
> JDK16. That is where new features are developed and eventually
> integrated.
>
> https://hg.openjdk.java.net/jdk/jdk/
>
> If the project comes through, you'd probably want your own repository
> that is based on jdk/jdk.
>
> Also, try to keep it under the JVMCI interfaces. If those are not
> sufficient, we shall work to make them a better fit. Better to keep it
> sane from the start.
>
> > If anybody else works in the same direction or just has some interest
> > in
> > the same area - we would be happy to cooperate.
>
> I am in favor of this project going forward, even though I doubt I can
> contribute very much to it due to lack of time. I'll be happy to assist
> though.
>
> Cheers,
> Roman
>
>
>