graal

native-image performance without PGO might be worse than with JIT, at least in some experiments that I did. See also https://github.com/oracle/graal/issues/979

Looking at the license [1], it appears to be GPL v2 with a classpath exception. This means it doesn't directly deal with the issue of patents, only copyright. There have been cases in the past of companies going after users for patents on otherwise open source projects. The worst part is, Oracle reserves those right so they can decide retroactively to go after those users (unless Oracle decides to modify/replace the license). [1]: https://github.com/oracle/graal/blob/master/LICENSE

WASM: https://github.com/oracle/graal/issues/1358 Wasn't able to find anything about RISC-V, file an issue :)

https://github.com/oracle/graal The evolution from MaximeVM, which is now increasingly being integrated into OpenJDK as part of project Metropolis. As for the CLR, it supports VB.NET, C++ and C# since day one, including a Common Language Specification and Common Type System. Then alongside its history got COBOL, Eiffel, F#, Ruby, Python, Nermele, Clojure,.... IBM and UNISYS mainframes language environments support a mix of COBOL, C, C++, Fortran, RPG, NEWP, also with a common type system for interoperability. While UNISYS documents are a bit hard to come by, IBM ones are available as RedBooks.

You can compile java to LLVM or create dll/so files. * https://www.graalvm.org/ * https://www.graalvm.org/docs/reference-manual/aot-compilatio... You only need to pass `--shared`. (You can also define multiple exports via public static ... and some annotations https://github.com/oracle/graal/blob/master/substratevm/READ...) of course it's a little bit akward to first create a "JVM" library and then call that library from native code, but it's not impossible.

> No mention of Windows Indeed. That description should be fixed. One click away there is a Windows build: https://github.com/oracle/graal/releases

Ah nice, we do want to switch Nextjournal to Shenandoah eventually after reading http://clojure-goes-fast.com/blog/shenandoah-in-production/ So is graal polyglot already compatible with newer JDKs and it's just native image generation that's blocking the upgrade? https://github.com/oracle/graal/issues/651

It's something that I hope would exist one day. Loom is a project that I'm working on to add lightweight threads to the Java platform (https://wiki.openjdk.java.net/display/loom/) and Truffle is a framework that allows writing fast language runtimes for the Java platform or standalone that chrisseaton is working on (https://github.com/oracle/graal/tree/master/truffle).

"Analytics" generally means "cython only". The numpy dep ends up being a problem. Generally if you want python/java interaction, we maintain a tool called javacpp that handles this, we even bundle cpython: https://github.com/bytedeco/javacpp-presets GraalVM itself also depends on javacpp for a portion of its features (LLVM wrapper): https://github.com/oracle/graal/blob/315f5dcf69c2e73fd13a5f8... I'd be happy to answer questions about the overlap of the 2. I can say I happily execute python scripts from our embedded python and even point the python execution at an anaconda distribution.

See this real-world assembler for example https://github.com/oracle/graal/tree/master/compiler/src/org... Then take a random instruction https://github.com/oracle/graal/blob/master/compiler/src/org... See how it has common methods used by other instructions simdPrefix and emitModRM? Those are the abstractions.

Most simple cases of instructions seem straightforward to just go ahead and emit the bytes for. Then when you start to use more addressing modes you realise it gets to be a lot of code and it turns out there's a common pattern for everything. Here's a concrete example from an industrial assembler. Almost every simple instruction boils down this helper method which is parameterised by a bunch of flags and can then deal with all of them. https://github.com/oracle/graal/blob/f3a3576493f87abdea1045d... Even that looks complicated! But writing this per instruction (the simple case) would be insanely complicated.

Sulong is GraalVM's LLVM bitcode interpreter, so it's mentioned under LLVM in the release notes. Its code base has been merged into GraalVM's main repository at https://github.com/oracle/graal.