On a $50/mo Azure VM running Windows Server I’m able to run a jar via java.exe that prints a string to stdout and exits - in about 160ms end-to-end in a warm-ish environment (Prefetch, IO caching, etc)
Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.
It loads classes lazily, so your program can start up at `main` very fast, and you only pay for what you use. This might cause some application feature to start up a bit slower on first run, but the byte code format is very compact and can be parsed in a single pass, so I don’t think it would be significantly slower than ordinary machine code loading.
> It loads classes lazily, so your program can start up at `main` very fast, and you only pay for what you use
Right, but large Java programs use huge numbers of classes. They may load thousands of classes just during start-up.
> the byte code format is very compact and can be parsed in a single pass, so I don’t think it would be significantly slower than ordinary machine code loading
That's what I was wondering about. There used to be a flag in OpenJDK to disable bytecode verification to improve start performance, but it was deprecated in JDK 13 [0] and I think it's since been removed entirely. Its removal is understandable but I still wonder about the performance impact.
Edit: Now it’s down to 80ms - I guess at this scale it’s hard to pin down.