3 ms·

Straw-man article. The main problems with the JVM in my experiences are the slow startup, large memory use and added cognitive load. The first one he says doesn

Straw-man article. The main problems with the JVM in my experiences are the slow startup, large memory use and added cognitive load. The first one he says doesn't matter, the second he never addresses directly and the third he completely misses.

pjmlp 10y ago
Any Java developer worth his/her salt knows that the first issue has been fixed by commercial JDKs, and if it is really a big issue for their deployment scenario, where to buy such tooling.
discreteevent 10y ago
From the article: Slow startup -> 80ms. What are you using it for that 80ms is a problem? Memory usage: He explains why an AOT solution would use more memory. What is the cognitive load with the JVM? You install it and the type 'java my.jar' BTW the JVM can reduce cognitive load hugely when it comes to profiling or debugging because of the tools.
- eikenberry 10y ago
  I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they are quite common. Only knowing "java my.jar" means you have zero knowledge about the nature of your language's run-time and having a good understanding of your languages run-time is necessary to write good code. The more complex the run-time of your language, the higher the cognitive load of that language. His discussion of memory use doesn't mention the pre-allocation of the heap for the JVM. The memory used by the application itself is irrelevant when the JVM is what is actually using the memory.
  - floatboth 10y ago
    You can start up the VM in 80ms for sure, you'll just need much more time after that to load all the damn classes from the bloated libraries you're gonna use. (Especially terrible with functional runtimes like Clojure's.) > pre-allocation of the heap for the JVM Pre-allocation doesn't matter, it's not allocating physical memory?? The GHC Haskell runtime literally mallocs one terabyte when the program starts :D However OpenJDK/HotSpot's baseline memory usage is indeed higher than many other VMs'. Even if you compare with alternative JVMs: I tested a basic Jetty app — it used ~60 MB on JamVM, ~70 MB on OpenJDK.
- usrusr 10y ago
  Cognitive load might mean how you have to code completely against all assumptions, rules and conventions when you want control over things like memory locality for efficient caching and the like. Not a point I would stress too much, but it can be a valid consideration.

pjmlp 10y ago

Any Java developer worth his/her salt knows that the first issue has been fixed by commercial JDKs, and if it is really a big issue for their deployment scenario, where to buy such tooling.

discreteevent 10y ago

From the article: Slow startup -> 80ms. What are you using it for that 80ms is a problem? Memory usage: He explains why an AOT solution would use more memory. What is the cognitive load with the JVM? You install it and the type 'java my.jar' BTW the JVM can reduce cognitive load hugely when it comes to profiling or debugging because of the tools.

eikenberry 10y ago
I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they are quite common. Only knowing "java my.jar" means you have zero knowledge about the nature of your language's run-time and having a good understanding of your languages run-time is necessary to write good code. The more complex the run-time of your language, the higher the cognitive load of that language. His discussion of memory use doesn't mention the pre-allocation of the heap for the JVM. The memory used by the application itself is irrelevant when the JVM is what is actually using the memory.
- floatboth 10y ago
  You can start up the VM in 80ms for sure, you'll just need much more time after that to load all the damn classes from the bloated libraries you're gonna use. (Especially terrible with functional runtimes like Clojure's.) > pre-allocation of the heap for the JVM Pre-allocation doesn't matter, it's not allocating physical memory?? The GHC Haskell runtime literally mallocs one terabyte when the program starts :D However OpenJDK/HotSpot's baseline memory usage is indeed higher than many other VMs'. Even if you compare with alternative JVMs: I tested a basic Jetty app — it used ~60 MB on JamVM, ~70 MB on OpenJDK.
usrusr 10y ago
Cognitive load might mean how you have to code completely against all assumptions, rules and conventions when you want control over things like memory locality for efficient caching and the like. Not a point I would stress too much, but it can be a valid consideration.