Hacker News Reader

Comment by chrisseaton | Hacker News Reader

Yes there's some reported bugs.

We build entire JavaScript, Ruby, and Python interpreters using the native code generator, so we do know it works for non-trivial applications and libraries. I've also used it to do things like compile the third-party Apache SIS geospatial library for use from a native application without issue.

The author's tried just one benchmark - there are many other benchmarks and use-cases. Twitter report it's around 11% faster for their real and extremely large codebase, so we also know for other people it's significantly faster.

View on HN

Is it frustrating answering these types of questions? If I was a plumber, I'd get tired of people complaining about their WiFi not working.

That must be a nice benefit of being part of a large corporation is being somewhat more delineated from the hype cycle of innovations like this.

"Yes ma'am I understand your router keeps rebooting, but I made it so that you can flush your toilet now."

Out of curiosity, dynamic class loading seems like one of those things where you would need to embed an interpreter in the application itself. So how does one deal with such cases?

Dynamic class loading is not supported on SubstrateVM because there is no infrastructure built-in to parse bytecodes, interpret them, etc. Adding those in SubstrateVM would defeat the purpose of having a thin layer VM. But, you are right: you could have an interpreter in the application itself. However a simple bytecode interpreter would have very bad performance. In fact that's how Truffle languages run on SubstrateVM. As far as SubstrateVM is concerned the Graal/Truffle stack is an application, albeit an application that knows how to interpret/compile other languages. So an interesting exploration path is having a Truffle based Java implementation that could be embedded in the image on demand, and which could load classes dynamically. You could still compile your known Java classes AOT and defer the dynamic classes to the interpreter. You might pay the extra cost for memory footprint, code interpretation/warmup/compilation time, etc., but you would be able to slowly migrate more Java code from dynamic compilation into AOT.

Reply on news.ycombinator.com