5 ms·

A native Java "Hello World" can be around 8MB in size.[1] So, yes, 90MB is too much. 1. https://sergiomartinrubio.com/articles/getting-started-with-graalvm-and

A native Java "Hello World" can be around 8MB in size.[1] So, yes, 90MB is too much. 1. https://sergiomartinrubio.com/articles/getting-started-with-graalvm-and-java-native/ https://sergiomartinrubio.com/articles/getting-started-with-...

Waterluvian 3y ago
“The generated file is 7.7MB, which is quite impressive for a Java application since this executable does need a JVM.” I assume this is a typo and they mean “does NOT”?
- carbotaniuman 3y ago
  I think it isn't, and there saying it's impressive how small the JVM overhead is.
  - Waterluvian 3y ago
    Is the JVM inside that 8MB then I guess? That is pretty great. Originally I thought the alternative was “8MB but supply your own virtual machine.”
    - squeaky-clean 3y ago
      There's no JVM when using GraalVM Native Images, it relies on a JVM during the compile step (well, specifically GraalVM), but produces native code similar to compiling C. There's no virtual machine running bytecode, just entirely native code. So the size of the executable will depend on how many features of the JVM you need compiled into your executable. A pure java bytecode (bring-your-own-JVM) Hello World can be under 2KB pretty easily. Smaller than the equivalent C program. But of course, that's not including the size of your system JVM.
      - brabel 3y ago
        > but produces native code similar to compiling C. That's very misleading. For one, Java running native still needs a Garbage Collector, maintains Object headers which increase memory usage, can do things like reflection for configured classes, can load services via the ServiceLoader, schedule Threads and manage executors, and many other things that are "expected" to any Java application... in summary: native executables still have a Java runtime embedded into them (called Substrate VM, by the way), making them very different from C (much more like Go). Also,notice that native Java executables still tend to have a lower "peak performance" (i.e. once a "normal" JVM has warmed up, it will almost certainly be faster than a native executable because the latter cannot do JIT compilation to take advantage of runtime profiling, like a normal JVM does).
        pjmlp 3y ago
        It also misleading to think C doesn't have a runtime. https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-run-time-library-reference?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-ru... https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/compiler_manual/linker_description/11_linking_c_cpp_code/run-time-initialization-stdz0752677.html https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_... And many more, not feeling like linking documentation from all C compilers. In fact this is so relevant even for C, that ISO C has a special section for deployments without runtime support, named freestanding C. "In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. There are otherwise no reserved external identitiers. Any library facilities available to a freestanding propram are implementation-defined."
        brabel 3y ago
        That's not at all comparable. From your link: "Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly." You're trying to imply the Java native runtime is comparable to liggcc?? That's silly.
- pkphilip 3y ago
  A full Quarkus web application with REST uses just 12MB of RAM (with Graalvm). So yes, Java has come a long way
- deleted 3y ago
  [deleted]
Spivak 3y ago
I feel like using Graal for the comparison is cheating a bit because it's so fundamentally different from what bun is doing. You need to compare it to tools that ship class files and a JVM, or something like PyInstaller which will have much much more overhead.
- sshine 3y ago
  I wouldn’t call it cheating. I’d also compare against stripped Rust binaries statically linked against musl.
- kaba0 3y ago
  A leaned up JRE (only containing the base jdk classes) and an included hello world is 47.2MB.
- ptx 3y ago
  PyInstaller actually seems to have less overhead, in terms of space, not "much much more". Building a hello world script with "pyinstaller --onefile" gives me a 5.6 MB executable on Linux or 4.9 MB on Windows.
sgammon 3y ago
https://elide.dev https://elide.dev
tehbeard 3y ago
Part of that I imagine is the same problem deno has. ICU locale data is pretty hefty and there aren't says to trim it down.

Waterluvian 3y ago

“The generated file is 7.7MB, which is quite impressive for a Java application since this executable does need a JVM.” I assume this is a typo and they mean “does NOT”?

carbotaniuman 3y ago
I think it isn't, and there saying it's impressive how small the JVM overhead is.
- Waterluvian 3y ago
  Is the JVM inside that 8MB then I guess? That is pretty great. Originally I thought the alternative was “8MB but supply your own virtual machine.”
  - squeaky-clean 3y ago
    There's no JVM when using GraalVM Native Images, it relies on a JVM during the compile step (well, specifically GraalVM), but produces native code similar to compiling C. There's no virtual machine running bytecode, just entirely native code. So the size of the executable will depend on how many features of the JVM you need compiled into your executable. A pure java bytecode (bring-your-own-JVM) Hello World can be under 2KB pretty easily. Smaller than the equivalent C program. But of course, that's not including the size of your system JVM.
    - brabel 3y ago
      > but produces native code similar to compiling C. That's very misleading. For one, Java running native still needs a Garbage Collector, maintains Object headers which increase memory usage, can do things like reflection for configured classes, can load services via the ServiceLoader, schedule Threads and manage executors, and many other things that are "expected" to any Java application... in summary: native executables still have a Java runtime embedded into them (called Substrate VM, by the way), making them very different from C (much more like Go). Also,notice that native Java executables still tend to have a lower "peak performance" (i.e. once a "normal" JVM has warmed up, it will almost certainly be faster than a native executable because the latter cannot do JIT compilation to take advantage of runtime profiling, like a normal JVM does).
      - pjmlp 3y ago
        It also misleading to think C doesn't have a runtime. https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-run-time-library-reference?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/c-ru... https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/compiler_manual/linker_description/11_linking_c_cpp_code/run-time-initialization-stdz0752677.html https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_... And many more, not feeling like linking documentation from all C compilers. In fact this is so relevant even for C, that ISO C has a special section for deployments without runtime support, named freestanding C. "In a freestanding environment (in which C program execution may take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. There are otherwise no reserved external identitiers. Any library facilities available to a freestanding propram are implementation-defined."
        brabel 3y ago
        That's not at all comparable. From your link: "Most of the routines in libgcc handle arithmetic operations that the target processor cannot perform directly." You're trying to imply the Java native runtime is comparable to liggcc?? That's silly.
pkphilip 3y ago
A full Quarkus web application with REST uses just 12MB of RAM (with Graalvm). So yes, Java has come a long way
deleted 3y ago
[deleted]

Spivak 3y ago

I feel like using Graal for the comparison is cheating a bit because it's so fundamentally different from what bun is doing. You need to compare it to tools that ship class files and a JVM, or something like PyInstaller which will have much much more overhead.

sshine 3y ago
I wouldn’t call it cheating. I’d also compare against stripped Rust binaries statically linked against musl.
kaba0 3y ago
A leaned up JRE (only containing the base jdk classes) and an included hello world is 47.2MB.
ptx 3y ago
PyInstaller actually seems to have less overhead, in terms of space, not "much much more". Building a hello world script with "pyinstaller --onefile" gives me a 5.6 MB executable on Linux or 4.9 MB on Windows.

sgammon 3y ago

https://elide.dev https://elide.dev

tehbeard 3y ago

Part of that I imagine is the same problem deno has. ICU locale data is pretty hefty and there aren't says to trim it down.