Hacker News Reader

Comment by mhansen | Hacker News Reader

Good article, but it seems to ignore the elephant in the room: the JVM's cold start times.

For me, git's use case is being called from the command line, often interactively, between code editing sessions. It needs to start fast and finish fast, to not interrupt my workflow.

The JVM's cold start times are huge. On the order of a second. Noticeably slow. So slow, that in the common case of committing a few files, the JVM startup time would totally dwarf the time spent actually doing work.

View on HN

The point of JGit was to provide a Git plugin for Eclipse. In this case the start-time is "outsourced" to Eclipse.

Seems like there are many other potential uses for this: other Java IDEs, web applications, integration into Java SCM tools - places where Git would be very useful and start-time can be neglected.

Run the java app as a server.

I did this with javac, and went from 5000ms (ant) to 200ms (averages). It gets faster each time it runs, enormous speedup after the first run; but still very significant for the next 10; and continuing at a slower rate from then on.

The client needs to be non-java, to avoid the startup cost there. I run it as a console, so that is the "client" (wrapped in rlwrap, for filename completion/editing etc). My workflow is to compile in a separate shell; that's why I did it this way.

JGit isn't meant to be a replacement for git on the command-line. It's meant to be used inside IDEs and web servers that 1) are already running on a JVM, 2) need to interact with git, and 3) don't want to pay JNI costs. JVM start-up times are a non-issue for these use cases.

Is the cost of JNI really that high? I'm curious--I haven't used it myself, but a client of mine is using it in a very latency-sensitive Java applet that uses JNI to call libavcodec to decode a video stream and then immediately display it through Java's own native libraries, so I would think the cost isn't that high.

The real cost of JNI is when you hotspot crash and take out the entire JVM instance (say your servlet and all your Tomcat instance as well)

I don't like anything calling out to JNI unless it's the only sane way and it's been heavily tested.

Check out nailgun if you're interested in using the JVM as a command-line tool without a cold-start.

http://martiansoftware.com/nailgun/index.html

I was looking at this the other day and am concerned that it hasn't been updated since February, 2005. That's practically ancient in terms of software.

and yet it functions perfectly with no problems when I use it in the VimClojure plugin. Tex hasn't been "updated" in ages either yet its fully functional. Sometimes software is just done and no further activity is needed. Judge it on whether it works not the date of the last commit.

Well as the github repo posted above you attests, there are (unsurprisingly) some non-trivial bugs in the last official release.

Unmaintained code is just not something I would ever use in a production capacity/rely on for my daily work. Especially considering the changes which have come to java and the jvm since 2005.

This looks unofficial, but Github has a version that has updates over the past few years:

http://github.com/ato/nailgun/tree/master/nailgun/

Disclaimer: I'm very much not a Java/C# guy, so this might be totally barking up the wrong tree. :-)

Would it be a speed win to keep some JVM processes "half-started" if load and memory use allowed? The next started Java app will use one of the already half started JVMs.

You wouldn't need to do anything fancy to keep the JVMs around; if a half-started JVM wasn't used for so many seconds that it might be swapped out, you half-start another JVM and throw away the timed out one.

(Hmm.. I don't remember, but another process could take over stdin/-out/-err? Or you could just limit this to non-console applications.)

How much of the work time is in initializing the JVM and how much is specific for initializing the application? Could the JVM data structures (JIT etc) for an app be cached between runs?

Edit: Made a little clearer. Moved disclaimer to the top, so people know they can stop reading if I'm in the wrong forest..

Edit 2: I probably have read and unconsciously copied a similar idea that some Perl guy implemented?

Apache in pre-forking mode might have inspired you. High availability Java might be relevant.

Reply on news.ycombinator.com