Multi-tenant Java 8 VM in beta

For a persistent JVM, take a look at Nailgun [1].

Additionally, the Drip project [2] uses a swapping strategy, by keeping an additional JVM spun up in the background. It was apparently built because the authors had trouble with persistent JVMs containing old dependencies.

[1] http://www.martiansoftware.com/nailgun/

[2] https://github.com/flatland/drip

javac is itself written in java, so you can write a little program that does that in a loop, waiting for some trigger. I actually just had it in a shell, waiting for you to hit return, which also called my code after compilation.

An unexpected benefit (unexpected to me, anyway) was that not only do you avoid the startup penalty, but you also benefit from JIT compilation of javac itself - every time it compiles, it gets faster! IIRC it's fairly substantial the first 10 times, but still improving at 50.

Here's a working minimal starting point I just put together for you (check docs, google, stackoverflow etc):

  import javax.tools.*;
  import java.io.*;

  class Demo {
    public static void main(String args[]) throws IOException {
      JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
      int result = compiler.run(null, System.out, System.out, args);
    }
  }

 java Demo Foo.java     # compiles Foo.java

Here's a stackoverflow answer suggesting something similar http://stackoverflow.com/a/793913/50979

BTW: I called out to a bash script to work out which source files had changed, because it's easier than writing that bit in java (and this compiler doesn't do that for you - it just compiles the explicitly listed source files).

HTH - let me know if you need more info. I've been thinking of using Jnotify to watch for source files being written to, so it's 100% automatic - one issue is that I save quite often, and each will trigger a compile (I'm doing this with plain javac and inotify at the moment).

This doesn't answer your question, but I suspect you may have a hazy recollection of something called "green threads"[1]. Green threads existed in early versions of Java (Java 1.1 and below) back in the days when operating systems had trouble with spawning large numbers of threads from a single application.

In the Java 1.1 & Linux 2.0 days you could get better Java performance by using green threads. That didn't last long, and around the time Java was being used for server-side applications it had mostly switched over to native threads.

So far as your actual question goes: There is little difference between the Java threading implementation on Linux & Windows.

[1] http://en.wikipedia.org/wiki/Green_threads#Green_threads_in_...

I think it's just an ontological issue, as well as Linux having more flexibility in what a process can share with its parent (via clone() flags).

The Linux scheduler schedules processes; the Windows scheduler schedules threads. Via clone(), Linux can create a process that shares almost everything with its parent, and thereby looks mostly like a Windows thread.

With regards the JVM, there is little difference in this specific respect. The sync primitives available on each platform are a bit different though, as well as things like signals.

What's the difference? In both cases, threads have their own stacks but share the rest of their address space. Is there a distinction other than terminology?