Introduction of Alhambra project
rkennke at redhat.com
Mon Jul 20 08:00:07 UTC 2020
I didn't mean to suggest to use Graal as front-end, I only meant to
suggest to use or extend JVMCI or build another reasonable compiler-
interface for Hotspot.
I'd also suggest to develop new features in the development branch
(currently JDK16) - or a fork of it under your project umbrella once it
Thanks and best regards,
> 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,
> On Tue, Jul 14, 2020 at 11:37 PM Roman Kennke <rkennke at redhat.com>
> > 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
More information about the discuss