3 ms·

What would you think would be gained by having non-VM based implementations of these by default? For the JVM, considerably lower startup/JIT warm-up times. You

What would you think would be gained by having non-VM based implementations of these by default? For the JVM, considerably lower startup/JIT warm-up times. You can really observe this nicely if you're using Zinc (the incremental Scala compiler), where you not only cut the startup overhead down to pretty much zero, but compilation really speeds up once the JIT has warmed up a bit. (Hence why Nailgun exists.)

Jtsummers 13y ago
I only have a passing familiarity with Scala so I had to look up Zinc, and my hobby languages are erlang/lisp and work is C# so Nailgun is also new to me. Nailgun seems to be a way to keep the JVM running so you don't incur the startup overhead. Straightforward enough, and makes sense when your execution time is dominated by the JVM init. Zinc seems to be a compiler based on Nailgun so that performance improves over time (particularly useful for long compiles or frequent compilation). Neither of those though, move Java off a VM/JIT basis. However, as someone who hasn't seen them before, it was interesting reading and neat to see what's going on in the rest of the world.
- rbehrends 13y ago
  Neither of those though, move Java off a VM/JIT basis. That's the thing; the Nailgun workaround to an extent avoids the startup overhead, but can create other problems. E.g., when you're starting multiple builds on the same server (because the Nailgun server listens on a port, so you may have to sort out conflicts), if you have multiple users on the same machine (because anybody can connect to the socket, so you have a potential security problem), etc. With a native option, this can be avoided (note that IBM offers an AOT compiler for Java).
  - Jtsummers 13y ago
    Note: I'm not saying a native option doesn't make sense, my original question is what would be the benefit for Java/C# (though we've focused on Java) of native first. Re: Nailgun - that seems like an implementation issue, but yes, if native compilation were present then Nailgun wouldn't exist (or need to) so the technical issues causing those problems wouldn't exist.

Jtsummers 13y ago

I only have a passing familiarity with Scala so I had to look up Zinc, and my hobby languages are erlang/lisp and work is C# so Nailgun is also new to me. Nailgun seems to be a way to keep the JVM running so you don't incur the startup overhead. Straightforward enough, and makes sense when your execution time is dominated by the JVM init. Zinc seems to be a compiler based on Nailgun so that performance improves over time (particularly useful for long compiles or frequent compilation). Neither of those though, move Java off a VM/JIT basis. However, as someone who hasn't seen them before, it was interesting reading and neat to see what's going on in the rest of the world.

rbehrends 13y ago
Neither of those though, move Java off a VM/JIT basis. That's the thing; the Nailgun workaround to an extent avoids the startup overhead, but can create other problems. E.g., when you're starting multiple builds on the same server (because the Nailgun server listens on a port, so you may have to sort out conflicts), if you have multiple users on the same machine (because anybody can connect to the socket, so you have a potential security problem), etc. With a native option, this can be avoided (note that IBM offers an AOT compiler for Java).
- Jtsummers 13y ago
  Note: I'm not saying a native option doesn't make sense, my original question is what would be the benefit for Java/C# (though we've focused on Java) of native first. Re: Nailgun - that seems like an implementation issue, but yes, if native compilation were present then Nailgun wouldn't exist (or need to) so the technical issues causing those problems wouldn't exist.