Introduction of Alhambra project

[Roman Kennke]

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