Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm curious, is there a JVM which runs as an OS daemon, and forks when a new process should be started in it ( i.e. like init, or zygote process on Android )? If no, why not? I am not talking about a daemon thread within the JVM.

The reason why I'm asking, is because the JVM startup time is quite slow, and incurs a heavy toll on scripting.

share|improve this question
    
Suggest that mods migrate this to StackOverflow as it is more of a Java coding question. –  Arcege Mar 5 '12 at 21:59
    
@Arcege I disagree; this is a question on how a JVM fits in a unix environment as opposed to an Android environment, with no Java coding involved. It is squarely on-topic on Unix & Linux and only marginally on-topic on Stack Overflow. –  Gilles Mar 6 '12 at 9:34
add comment

4 Answers

up vote 3 down vote accepted

JVM startup time is quite slow, and incurs a heavy toll on scripting . . . huge optimization for java process startup time.

The other answers answer the question with respect to generic app startup, which are useful considerations.

But seems your primary question is Java application startup performance re overhead of starting a jvm. This has also been my question. I found this:

If willing to sacrifice user-separation security, check out Nailgun, an Insanely Fast Java:

Nailgun is a client, protocol, and server for running Java programs from the command line without incurring the JVM startup overhead. Programs run in the server (which is implemented in Java), and are triggered by the client (written in C), which handles all I/O.

share|improve this answer
    
Thanks, this is more in the line I was looking for. :) –  zacsek Aug 27 '12 at 16:20
add comment

Android uses a single Zygote process that forks to start a new application. This optimization is possible because all Android applications start in the same environment; there is very little to do (mainly set the user and load the application code) to launch an application. This optimization is effective because there is little to do, especially since the Zygote process already has the libraries linked in.

On a unix system, the assumptions that underlie Zygote are not met. Each process starts with its own environment variables, its own open files, its own usage limits, its own user and groups, etc. You can't transfer all these properties from one process to another (you can transfer some, but even then that would mean additional startup time). Furthermore, there is a wide range of different libraries used by different applications; each application would have to load its own. A Zygote-like optimization is neither possible in general nor, in many cases, really helpful even when it's possible.

You can write a Java program that's a daemon. It's something you have to manage on an application-by-application basis. You can make your application start as a daemon and fork when it gets a new request. It's up to you to decide what to do when forking.

share|improve this answer
    
Good answer. I'd like to point out that java doesn't have the unix fork/exec mechanism but only a command executor (which is not a real, fast fork) or it's own threading model, which is very fast and used by application servers. Processing isolation is done via OSGI and/or classloaders, but it's not the same as two different processes where one of the processes can crash and the other survives without a hitch. OTOH, this is not a common thing in Java, where these problems manifest themselves in the form of exceptions. –  vasquez Mar 6 '12 at 7:14
    
I have to (partly) disagree with you: I think that a JVM process running as a spawning process for Java (or other JVM compatible) applications can have lots of useful assumptions, like that the process will use a lot of the java runtime system library ( rt.jar is itself 40 MBs ). Preloading that, and sharing it like a dynamic library would be a huge optimization for java process startup time. If you are using Groovy or JRuby to execute a one-line script repeatedly, almost all of the execution time will be for JVM startup. –  zacsek Mar 6 '12 at 10:48
1  
@zacsek “can have lots of useful assumptions”: did you mean lots of useful applications? Yes, there are some useful applications, but you can't implement it in a fully generic way. There may be Java libraries to help you make a forking application; for that you should ask on Stack Overflow. –  Gilles Mar 6 '12 at 11:01
add comment

Any process, including a java program, can run as a daemon. The real question is if the Java implementation has all the system calls to make it into a "proper daemon process" (for example, signal processing, session/process group handling, etc.). You might want to look at the Java Daemon API.

Also, since OS forking will creating a copy of the running program, there will be no startup costs, only the cost of creating a new process data structures within the OS. Performing a subsequent exec may incur startup costs. Threading is often used in place of forking for Java programs since there is already a stable API.

share|improve this answer
    
What I meant was, if the JVM process itself is daemonizable, making it behave essentially like the init process: the JVM is always running, all its essential classes are loaded, cached in memory, so when I execute a java -jar Something.jar, it will fork itself, loading only the classes of the user app, while the JVM daemon becomes the parent process. –  zacsek Mar 5 '12 at 22:01
    
It is possible, but again, you should be looking at what the API offers. The way that fork works is both the parent process and child process start immediately after fork returns, the only thing different (besides the pid/ppid and memory) is the return value: 0 for the child and for the parent, the child's pid. The JVM can take over to load classes as needed. This is essentially what Tomcat and other app containers do (albeit through threads). This is not the distinguishing behavior of a daemon, but of a spawning process. A daemon is detached from any terminal or user intervention. –  Arcege Mar 5 '12 at 23:19
1  
@zacsek I think there were ideas to do it like that, but they never took for various reasons. I remember Sun had ideas for a "java computer" that would execute bytecode just like normal programs, but the JVM wasn't that flexible. They did optimize a lot with the startup times for a jvm, like a quickstarter and class data sharing, see en.wikipedia.org/wiki/Java_performance –  vasquez Mar 6 '12 at 7:20
add comment

Actually, application servers like JBoss provide functionality similar to (but not the same as) what you're asking for: A Java process runs in the background, and you can instruct it to start a sub-application. The downside of this approach, however, is that the sub-applications are not started as separate processes, so they are not safely separated: if one crashes the VM, or calls System.exit(), or decides to interrupt() all Threads, all other sub-applications are also affected.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.