3 ms·

I think the problem is because of the virtual machine, instead of being compiled to an executable. I mean GraalVM is great - but why did it take so long to deve

by huonib 5y ago

I think the problem is because of the virtual machine, instead of being compiled to an executable. I mean GraalVM is great - but why did it take so long to develop? I mean Sun could still be alive if developers and users had instant startup times, could have easily deployed Java to servers and clients, and that it was not only faster but used way less memory.

mnd999 5y ago
The virtual machine is (was?) the whole point. You can run the same binaries on your dev box or your server, whatever flavour of server that happens to be. Startup times are not an issue on servers as processes are typically long-lived anyway. It is a bit of an issue on serverless (lambda etc.) but that’s a relatively new thing. High memory usage is generally poor tuning - if you give the JVM 1gb it will use it and avoid GC until it needs to. Sometimes it’s poor coding too, I’ve seen web APIs accepting files as base64 encoded json strings which is horrific server side.
- huonib 5y ago
  I'm sorry, did you claim poor tuning? look at this graph: https://alvinalexander.com/sites/default/files/inline-images/java-v-graal-memory-annotated.jpg https://alvinalexander.com/sites/default/files/inline-images... from: https://alvinalexander.com/scala/graalvm-native-executables-faster-than-scala-java-jvm-apps-less-ram/ https://alvinalexander.com/scala/graalvm-native-executables-...
  - mnd999 5y ago
    Graal is very clever, but that memory example is nonsense. I just tried the Find example they give and whether the graal version beats the java version is completely dependent on Xmx. Obviously I don't have their dataset, so it's not exactly the same test. edit: In fact the numbers in the blog are so far off mine they may accidently have been testing /usr/bin/find.
kaba0 5y ago
It didn’t take too long, there was AOT compilers available two decades ago as well. There was just not much interest in it, because performance gets worth, and startup time is seldom interesting. (Pretty much only command line tools would require faster startup, and recent serverless) And memory usage is a tradeoff. Though most of the time java could run with almost half of the currently used memory, it is unnecessary work to GC if memory is available.
lelanthran 5y ago
> I think the problem is because of the virtual machine, instead of being compiled to an executable. I learned Java on gcj (gcc support for Java), and it generated executables. I've no idea why they killed it. Maybe someone more in the know can explain.

by huonib 5y ago

mnd999 5y ago

The virtual machine is (was?) the whole point. You can run the same binaries on your dev box or your server, whatever flavour of server that happens to be. Startup times are not an issue on servers as processes are typically long-lived anyway. It is a bit of an issue on serverless (lambda etc.) but that’s a relatively new thing. High memory usage is generally poor tuning - if you give the JVM 1gb it will use it and avoid GC until it needs to. Sometimes it’s poor coding too, I’ve seen web APIs accepting files as base64 encoded json strings which is horrific server side.

huonib 5y ago
I'm sorry, did you claim poor tuning? look at this graph: https://alvinalexander.com/sites/default/files/inline-images/java-v-graal-memory-annotated.jpg https://alvinalexander.com/sites/default/files/inline-images... from: https://alvinalexander.com/scala/graalvm-native-executables-faster-than-scala-java-jvm-apps-less-ram/ https://alvinalexander.com/scala/graalvm-native-executables-...
- mnd999 5y ago
  Graal is very clever, but that memory example is nonsense. I just tried the Find example they give and whether the graal version beats the java version is completely dependent on Xmx. Obviously I don't have their dataset, so it's not exactly the same test. edit: In fact the numbers in the blog are so far off mine they may accidently have been testing /usr/bin/find.

kaba0 5y ago

It didn’t take too long, there was AOT compilers available two decades ago as well. There was just not much interest in it, because performance gets worth, and startup time is seldom interesting. (Pretty much only command line tools would require faster startup, and recent serverless) And memory usage is a tradeoff. Though most of the time java could run with almost half of the currently used memory, it is unnecessary work to GC if memory is available.

lelanthran 5y ago

> I think the problem is because of the virtual machine, instead of being compiled to an executable. I learned Java on gcj (gcc support for Java), and it generated executables. I've no idea why they killed it. Maybe someone more in the know can explain.