>> I’m also curious about the runtime footprint in general; any idea what is the smallest possible VM for a real but relatively-small language like Lua?

> Real language VMs are quite a bit bigger - a hundred MB or so.

Don't know if you're trying to say Lua is not a real language, or just skipped the part about Lua.

No, hello-world executables built using SVM are 5 MB or so. Real world language VMs built using SVM are a hundred MB or so. If you had a language VM for the real world language that is Lua built using SVM it would probably be a hundred MB or so.

I'm not passing any opinions about any languages or VMs here.

> If you had a language VM for the real world language that is Lua built using SVM it would probably be a hundred MB or so.

Is this mostly JRE? Would Jigsaw help, or is SubstrateVM already doing something like that? (To be clear, this tech is really impressive! Just trying to get a sense of embeddability constraints)

The SubstrateVM already does whole-world analysis to only compile methods that are actually used, so reducing the methods in the JAR before hand (which is what Jigsaw) would do, would not change anything.

Language VMs compiled using SubstrateVM are larger than you may think because as well as the native code they also need to contain a representation of the code that the compiler can read (IR) so it can dynamically compile the methods that are combined to form the compiled version of your user's code, and we also need to compile a sort of runtime debug information that allows us to jump from optimised code back to the native code when an optimisation proves to be wrong. This is a novel thing - most language VMs jump from optimised code to a bytecode interpreter - we have to jump back to the native code as there is no bytecode interpreter. Finally, a language VM also needs to include all of the Graal compiler itself for dynamic compilation, which is quite a bit of code.

Ah. Sorry I misread. :)