If you want to reduce the time required to handle an individual request in a given program that you already have there's not much you can do automatically. You can't use a processor that's twice as fast because if you are already using a modern system we don't have one of those. You can't use two processors as we don't really know how to parallelise effectively enough in general cases. But you can double the RAM in a system with reasonable effort and cost.

The startup time issue is being solved with ah ahead-of-time Java compiler with whole-world analysis that we are developing. It runs hello-world in our Ruby implementation in about 100ms, which is an order of magnitude faster than the normal JVM.

OK, if those are your design constraints, then that's fair. I'm just questioning how widely those constraints will apply in the future.

I'm pretty sure the v8 changes were motivated by phones, so maybe there is room for another project like Graal and Truffle with a different set of constraints.

Also, for web services in particular (not sure if that is a major use case), I would question the view of making individual requests faster. I recall Steve Souders said he was a back end guy at Yahoo working on latency, and then he switched to front end performance because he found that the front end was eating up all the time.

In my experience this is too true. In other words, if you had a server where requests were taking 100 ms, and you made them take 50 ms through VM design, you would be a hero! But somehow front end engineers are still constructing pages with 10 - 30 full seconds of latency (especially on mobile) out of back end requests that take 100ms. There's just a lot more room to optimize there, whereas sometimes I feel like VMs are trying to squeeze blood out of a stone.

And I agree that there will be demand for such a "black box" approach, where you just take an arbitrary program and make it faster. But I'm interested in overall system performance, and in that case, a little bit of application knowledge can work wonders. One of my pet peeves is that often performance tools like time and space profilers are sort of an afterthought that programmers use only when they have problems. They write this huge spagehetti of allocation, and then 2 years later they start tuning the GC.

This is partly the fault of programmers and partly the fault of the language ecosystem. It would be nicer if the language exposed integrated tools. I dont' know that much about the JVM ecosystem, but they always feel like a "separate thing" you have to go research and choose and download and install. I think Go's tooling is a good example here.

Anyway, I think this is an interesting project. In particular I think the focus on polyglot programming is fantastic. I too feel the pain of enormous amounts of duplicated work -- e.g. even at say Google with a relatively small set of languages like C++, Java, and Python, there were still all these separate "worlds" and gradually engineers became sequestered in their own world. IMO Go made things worse and not better -- it was yet another native runtime that didn't even interoperate all that well with C++, let alone Java or Python!!!

That's an interesting argument I hadn't considered before.

>> "making startup time even worse than the JVM itself makes it unattractive

Agree.

Do you know if this can generate native code without any JVM dependencies? For instance, could I implement a C compiler that outputs optimized native code just like gcc or clang?

At any rate, it sounds like this research could be used to produce the tools we want, even if this is not it. For instance, PHP could use a JIT, if it didn't cause slow warm-ups and blow up memory usage.

> Do you know if this can generate native code without any JVM dependencies?

Yes it can! However you get a native VM that doesn't need the JVM for your language. You don't get a native executable for your application.

How applicable do you think it would be to PHP?

I don't think there are any language features in PHP that we haven't already tackled for Ruby, JS or Python.