graal

VisualVM and JVM reflection/introspection depend on HotSpot, and on GC safepoints, and so on. GraalVM uses its own GC, and has some limitations: https://github.com/oracle/graal/blob/master/substratevm/Limi... (basically it needs to statically know what will be accessed via reflection, so it can add those to the native-image). In theory, sure it can be made to work with VisualVM. But I'd be surprised if it works out of the box.

Currently, you'd use the polyglot package that ships with the GraalVM SDK: https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Con... Here are a couple of demos: https://github.com/graalvm/graalvm-demos I said "currently", because you currently have to use the host Java, that is the Java on top of which all other languages are implemented. The GraalVM team is working on Project Espresso, a Java written in Truffle. That will make polyglot programming with Java much more consistent with the rest of the languages. Project Espresso isn't public yet, but here's the latest update from the team working on it: https://github.com/oracle/graal/issues/1656#issuecomment-664...

GraalVM consists of a couple of things. 1. A modern JIT compiler written in Java that takes bytecode and transforms it into machine code. There is a plan that it might someday replace HotSpot [1]. However, we are probably a couple of years away from this. 2. A native image compiler [2] that uses ahead-of-time compilation technology to produce executable binaries of class files. This means startup times and memory usage similar to a language such as go. 3. An abstract syntax tree interpreter called Truffle. Which allows you to easily implement languages on top of GraalVM. With the performance of compiled languages but using an interpreter. You can read more about this here [3]. There are also other features such as a LLVM bitcode engine called Sulong. And various PolyGlot functionality to support integration of whatever language you want.

> Remember there has been a tremendous amount of effort made to make VM's like the JVM ... performant on ARM for mobile. This doesn't reflect what I'm seeing at all - in fact I'm seeing basic ARM intrinsics still being added to the Graal compiler in the last few weeks! https://github.com/oracle/graal/pull/2588 > You really can just drop you jar on an ARM (m6g), AMD (m5a) or Intel (m5, m5n) expect the same results. Not without these kind of basic intrinsics you won't!

Well I don't know what to tell you except this is how real production compilers written by experts work in practice. https://github.com/oracle/graal/blob/4553ea71f15c9e4721565e9... You can argue this is a bug and they shouldn't write like this, but they don't consider it a bug and they do write like this.

These are different things. https://github.com/oracle/graal/blob/master/substratevm/LIMI... Where SBCL just adds some compiled code, writes a memory dump out in a second. Then this can be run as a new SBCL with added code - it still includes the compiler, and all other stuff. One can also then add more code and write another image... The new image is just like the other one, just with more code and otherwise the usual feature set. This includes the whole SBCL and my code, not just a static application with limited dynamic features. Many Common Lisp systems have a way to write a snapshot of the developed environment, which then starts in subsecond. Additionally some Common Lisps have ways to do application or shared library delivery, which can remove dynamic features, remove parts of the development tools, remove unused code/data, etc. Thi