3 ms·

AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrast

AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. Also, going all-in on async doesn't seem that helpful on the JVM where the vast majority of existing code (= what makes the JVM valuable) uses synchronous I/O. So what's the point of this? To start a webserver really fast? I always thought the value of vert.x is to become part of a node.js/CommonJS runtime for the JVM (like what Oracle and RedHat were trying a couple years ago).

kuschku 8y ago
> AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. That’s true with the JVM’s AOT project, but SubstrateVM is entirely separate – you get a single binary that runs standalone.
thermodynthrway 8y ago
I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and most DB calls are fast enough that it never happens. The one place it makes a huge difference is when you're waiting on other, possibly slow, services like third party REST calls. If you have 100 threads and each call takes 1000ms you will run out of threads at 100 req/sec which is quite low for the JVM. Using async in these situations allows thousands of threads to be paused while your 100 still do work, allowing you to handle maybe 10k req/sec even with a slow partner service. A lot of JS programmers don't understand the relation between thread starvation and async, they act like async is magic. If you're not thread starved (everything you do is pretty quick) then async is useless
- apta 8y ago
  > I've messed with async on JVM. What library or framework did you use? Using ExecutorService or similar would still have those 100 threads blocked even if they run in their own future, correct? The only thing it would allow is queuing the other incoming requests, but it does not time slice or switch to another request upon hitting an IO request.
  - thermodynthrway 8y ago
    You can use fiber libraries like quasaras your executor, just like Go uses for regular threading. The double edged sword of Java is that you can do anything. But the learning curve is huge because there's so much crap out there
BenoitP 8y ago
If I had to bet on that, I'd say it is a move to make it a really great platform for serverless; where it can absorb trafic spikes with ease, and go to sleep very fast. The logic required in a typical web server is not complicated. Most of what the hardware does is filling and emptying memory/caches, waiting for the disk or the network, etc. Most useful computations are like very thin spikes that need a vast context to exist. All the current work being done is to carve a lot of this context down. Doing this will drive the operating cost down a lot. The JVM has several other initiatives in the spirit of this. Consider these 2 JEPs that just got added: * Dynamic Max Memory Limit [1] * Timely Reducing Unused Committed Memory [2] There is also the Loom initiative [3], to provide a base for blocking-code-like to run on very cheap threads; providing tiny threads with a tiny context. IMHO these make it possible to have an AWS lambda service that has a typical wake up time in the 10us, rather than a few 100ms. Your functions (and CPU costs) could sleep in-between IO/disk/network requests! [1] http://openjdk.java.net/jeps/8204088 http://openjdk.java.net/jeps/8204088 [2] http://openjdk.java.net/jeps/8204089 http://openjdk.java.net/jeps/8204089 [3] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...
kodablah 8y ago
> Also, going all-in on async doesn't seem that helpful on the JVM where the vast majority of existing code (= what makes the JVM valuable) uses synchronous I/O. I'm not sure that the majority of many-year old backwards compatible code being sync IO has much to do with the value of async. So long as there're ample amounts of async code/libs. I wrote a backend in Scala using an async Postgres lib. I hopped over three different ones before writing my own, all of which are async. For things like network IO in fact, there may be more maintained async code than sync code.

kuschku 8y ago

> AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC. That’s true with the JVM’s AOT project, but SubstrateVM is entirely separate – you get a single binary that runs standalone.

thermodynthrway 8y ago

I've messed with async on JVM. In my experience, it doubles speed at most for CRUD apps with heavy DB access. Async is only useful if you're thread starved, and most DB calls are fast enough that it never happens. The one place it makes a huge difference is when you're waiting on other, possibly slow, services like third party REST calls. If you have 100 threads and each call takes 1000ms you will run out of threads at 100 req/sec which is quite low for the JVM. Using async in these situations allows thousands of threads to be paused while your 100 still do work, allowing you to handle maybe 10k req/sec even with a slow partner service. A lot of JS programmers don't understand the relation between thread starvation and async, they act like async is magic. If you're not thread starved (everything you do is pretty quick) then async is useless

apta 8y ago
> I've messed with async on JVM. What library or framework did you use? Using ExecutorService or similar would still have those 100 threads blocked even if they run in their own future, correct? The only thing it would allow is queuing the other incoming requests, but it does not time slice or switch to another request upon hitting an IO request.
- thermodynthrway 8y ago
  You can use fiber libraries like quasaras your executor, just like Go uses for regular threading. The double edged sword of Java is that you can do anything. But the learning curve is huge because there's so much crap out there

BenoitP 8y ago

If I had to bet on that, I'd say it is a move to make it a really great platform for serverless; where it can absorb trafic spikes with ease, and go to sleep very fast. The logic required in a typical web server is not complicated. Most of what the hardware does is filling and emptying memory/caches, waiting for the disk or the network, etc. Most useful computations are like very thin spikes that need a vast context to exist. All the current work being done is to carve a lot of this context down. Doing this will drive the operating cost down a lot. The JVM has several other initiatives in the spirit of this. Consider these 2 JEPs that just got added: * Dynamic Max Memory Limit [1] * Timely Reducing Unused Committed Memory [2] There is also the Loom initiative [3], to provide a base for blocking-code-like to run on very cheap threads; providing tiny threads with a tiny context. IMHO these make it possible to have an AWS lambda service that has a typical wake up time in the 10us, rather than a few 100ms. Your functions (and CPU costs) could sleep in-between IO/disk/network requests! [1] http://openjdk.java.net/jeps/8204088 http://openjdk.java.net/jeps/8204088 [2] http://openjdk.java.net/jeps/8204089 http://openjdk.java.net/jeps/8204089 [3] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...

kodablah 8y ago

> Also, going all-in on async doesn't seem that helpful on the JVM where the vast majority of existing code (= what makes the JVM valuable) uses synchronous I/O. I'm not sure that the majority of many-year old backwards compatible code being sync IO has much to do with the value of async. So long as there're ample amounts of async code/libs. I wrote a backend in Scala using an async Postgres lib. I hopped over three different ones before writing my own, all of which are async. For things like network IO in fact, there may be more maintained async code than sync code.