5 ms·

Many modern high-level languages use some kind of VM (most notably Clojure and V8). This is a means to provide a JIT, do runtime optimizations, and garbage coll

Many modern high-level languages use some kind of VM (most notably Clojure and V8). This is a means to provide a JIT, do runtime optimizations, and garbage collection. AOT means that you don't have a chance to do anything about the generated code at runtime. That said, the startup time of a monster like JVM is definitely problematic; the approach I'm taking is a thin VM.

exDM69 12y ago
> Many modern high-level languages use some kind of VM I don't think this is a good approach and it's very nice to see projects like yours that try to shift the paradigm. LLVM can provide many of the benefits of bytecode based VMs, yet give efficient native code in the end. How did you go about the GC? Did you grab a GC from somewhere else or build your own? Did you use LLVM shadow stacks and/or GC annotations? I guess Lisp is a lot easier to build a GC for than other languages. There are many promises VMs should give, performance, safety and security but in practice not a lot of those promises were ever fulfilled. Performance can be on-par with native code in the best case but usually 2-10x behind, safety may be a bit better but we still get crashes because of incorrect memory use and the Oracle JVM has had more zero day vulnerabilities than any other software I can name. I think it's time to move on.
- pjmlp 12y ago
  One issue with the current state of affairs with VM runtimes is that most developers without compiler developer knowledge, now think memory safe runtimes == VM. I really think Java did a left turn there, by not providing native compilers as part of the standard toolchain. At least .NET has NGEN and now will get .NET Native compilers as well. Yes, Sun/Oracle JVM had quite a few security vulnerabilities, but many were caused by the native code in the VM stack. While others were indeed caused by real bugs in library code. Still way less exploits that in C and friends. Besides that was one JVM, there are plenty of others out there which share 0% implementation with Oracle's.
- artagnon 12y ago
  The plan is to eventually stick with LLVM MCJIT with custom optimizations. There's really no point in producing an AOT binary. I don't do GC yet. I suspect it happens because the VM becomes too large and complex for anyone to debug.
  - sklogic 12y ago
    Are you doing some fancy region analysis (e.g., like in Harlan) instead of GC?

exDM69 12y ago

> Many modern high-level languages use some kind of VM I don't think this is a good approach and it's very nice to see projects like yours that try to shift the paradigm. LLVM can provide many of the benefits of bytecode based VMs, yet give efficient native code in the end. How did you go about the GC? Did you grab a GC from somewhere else or build your own? Did you use LLVM shadow stacks and/or GC annotations? I guess Lisp is a lot easier to build a GC for than other languages. There are many promises VMs should give, performance, safety and security but in practice not a lot of those promises were ever fulfilled. Performance can be on-par with native code in the best case but usually 2-10x behind, safety may be a bit better but we still get crashes because of incorrect memory use and the Oracle JVM has had more zero day vulnerabilities than any other software I can name. I think it's time to move on.

pjmlp 12y ago
One issue with the current state of affairs with VM runtimes is that most developers without compiler developer knowledge, now think memory safe runtimes == VM. I really think Java did a left turn there, by not providing native compilers as part of the standard toolchain. At least .NET has NGEN and now will get .NET Native compilers as well. Yes, Sun/Oracle JVM had quite a few security vulnerabilities, but many were caused by the native code in the VM stack. While others were indeed caused by real bugs in library code. Still way less exploits that in C and friends. Besides that was one JVM, there are plenty of others out there which share 0% implementation with Oracle's.
artagnon 12y ago
The plan is to eventually stick with LLVM MCJIT with custom optimizations. There's really no point in producing an AOT binary. I don't do GC yet. I suspect it happens because the VM becomes too large and complex for anyone to debug.
- sklogic 12y ago
  Are you doing some fancy region analysis (e.g., like in Harlan) instead of GC?