Multi-tenant Java 8 VM in beta(ibm.com)
ibm.com
Multi-tenant Java 8 VM in beta
http://www.ibm.com/developerworks/java/library/j-multitenant-java/index.html
5 comments
Fantastic for sharing, though the startup time improvement is minor (e.g. I saw 17% improvement). BTW: that SO comment references a pdf that shows how to include your own classes, on pages 61-62 http://www.oracle.com/technetwork/jp/ondemand/java/20110519-...; tools link: http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/make/tools...
IBM's multi-tenancy gives 3.3 speedup, for HelloWorld - worse for others (maybe if they combined it with CDS?)
BTW: The only way to get instant Java startup is not to startup - use an already running JVM, with the classes already loaded. It's fast. Just leave it in the background til you need it - it's effectively a server. Especially good to invoke javac this way, for lightening compiles (if like me you don't use an IDE).
IBM's multi-tenancy gives 3.3 speedup, for HelloWorld - worse for others (maybe if they combined it with CDS?)
BTW: The only way to get instant Java startup is not to startup - use an already running JVM, with the classes already loaded. It's fast. Just leave it in the background til you need it - it's effectively a server. Especially good to invoke javac this way, for lightening compiles (if like me you don't use an IDE).
If one needs to be launching only a fixed set of programs fast, perhaps give CRIU, checkpoint restore in userspace, a try? Give the program time to warm up and load, checkpoint it, then restore a copy: run an already copy, rather than repeat the startup afresh. Post on CRIU from the same day: https://plus.google.com/113218107235105855584/posts/CNkhcV43...
Interesting about keeping a JVM running for compilation. I'm curious about doing just this for my day job but can't seem to find a good explanation. Do you have any resources to point me to?
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
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):
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).
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
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).
I came across CDS before when trying to get desktop java applications to start up faster.
I also had hoped it would allow e.g. a constantly running fat server to run eclipse for multiple users more efficiently than each desktop duplicating work.
http://lukas.zapletalovi.com/2012/11/want-faster-java-startu...
I had thought CDS was just for Sun and IBM implementations, but from the above I can infer it works on OpenJDK too.
When you say, 'running many many java copies', do you mean java.exe?
I also had hoped it would allow e.g. a constantly running fat server to run eclipse for multiple users more efficiently than each desktop duplicating work.
http://lukas.zapletalovi.com/2012/11/want-faster-java-startu...
I had thought CDS was just for Sun and IBM implementations, but from the above I can infer it works on OpenJDK too.
When you say, 'running many many java copies', do you mean java.exe?
Not sure it is the first one: http://www.waratek.com/product/cloudvm
Didn't Sun have an experimental MVM about 10 years ago?
Does anyone know if .NET runtime is multitenant? Would be great to know about the alternatives (and their future plans).
.NET has a feature called 'application domains' which provides stuff pretty similar to this, but I don't know if the support is as complete. They use it for security sandboxing, on-demand code loading/unloading, etc.
http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
Yes, .NET has had Application Domains since the beginning. It can be used for exactly this purpose.
"You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability."
http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
"You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability."
http://msdn.microsoft.com/en-us/library/2bh4z9hs.aspx
.Net runs in various places. Under IIS, you're thinking of Application Pools http://stackoverflow.com/questions/3868612/what-is-an-iis-ap...
an app pool usually (without farm setting) translates to one w3wp process, so the deduplication doesn't take place. That would mean there's no real multitenancy in IIS via app pools.
> The main cost of using the multitenant JVM is that tenants are less isolated than multiple applications that run in separate JVMs. For example, a native crash in the multitenant JVM affects all tenants.
Does anyone know what exactly is meant by a "native crash"?
Does anyone know what exactly is meant by a "native crash"?
One permgen to kill them all
Question: I had the impression that when you had several threads on a Java app this would result in several VMs, is this currently so, was so or it's my mistake and it was never like that?
It was never like that. Threads have their own stack, but that's about it. They can access anything anywhere. Hence the current focus on concurrency using immutable message passing mechanisms on the JVM (actors etc.)
Or, to be more specific, what are the differences between thread handling under Linux and Windows regarding to the JVM?
Threads in Linux (in general) are separate process that share memory space, in Windows it's different and they're "threads" being scheduled under a parent process.
Threads in Linux (in general) are separate process that share memory space, in Windows it's different and they're "threads" being scheduled under a parent process.
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_...
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.
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?
Ah apparently not so much http://stackoverflow.com/questions/3237701/do-threads-create...
But I would say you would have definitely to watch for a) thread creation time and b) thread priorities (but for most of the applications these are not a problem)
But I would say you would have definitely to watch for a) thread creation time and b) thread priorities (but for most of the applications these are not a problem)
Links to notes on this, https://plus.google.com/113218107235105855584/posts/K9seVudj... . Stack overflow q, http://stackoverflow.com/questions/4692076/speed-up-applicat...
CDS is fantastically un-isolated and using it is going to be systemwide. You're still running many many java copies, and that is fat in size, ugly and busted in form. Containers like Tomcat exist to solve a near-like problem of being a many-application serving system. This virtualized virtual machine is definitely the first runtime that's oriented to multi-tenant, but if you look around, you can find some it's technical roots here and there.