sure the garbage collector make a difference but the big difference imho is how the VM interpret the bytecode.
In the JVM, the long startup time is because the bytecode is fully loaded, verified, etc. then interpreted
If you compare with other VM, like the AVM2 (ActionScript Virtual Machine 2), there the bytecode is considered as a stream, even if your program is many hundred of MB, the interpreter kick in much earlier.
It is explained in a presentation at Standord University by Rick Reitmaier from Adobe Systems
Wether you run the AVM2 from a shell script, a standalone executable or even as CGI under Apache, the avmshell which run, load, verify, interpret the bytecode, startup in matter of milliseconds.
sure the garbage collector make a difference but the big difference imho is how the VM interpret the bytecode.
In the JVM, the long startup time is because the bytecode is fully loaded, verified, etc. then interpreted
If you compare with other VM, like the AVM2 (ActionScript Virtual Machine 2), there the bytecode is considered as a stream, even if your program is many hundred of MB, the interpreter kick in much earlier.
It is explained in a presentation at Standord University by Rick Reitmaier from Adobe Systems
see at 31:35, https://youtu.be/BjYRzwDEIyw?t=1894 , he talk about startup time.
In my own experience working with AVM2 on my OSS project Redtamarin https://github.com/Corsaair/redtamarin , this startup time was key.
Wether you run the AVM2 from a shell script, a standalone executable or even as CGI under Apache, the avmshell which run, load, verify, interpret the bytecode, startup in matter of milliseconds.
But it is a trade, you could say
JVM: slow startup time, faster execution
AVM2: fast startup time, slower execution