Sounds what we need is the old UNIX sticky bit put back into Linux. The
sticky bit was a file attribute that told the Kernel that the
application should stay in cached for some period of time after it was
initially loaded. Way back when, UNIX did this and things that got hit a
lot like editors (vi, sed, etc) would stay cached in memory. Someting
like this could keep the JVM cached after it was initially started. The
initial startup could be something as simple as putting it in your
.profile, .login, or .bashrc with the instruction to print the version
upon initial login.
I'll drop in on one of the Kernel lists this week and see if there is
any interest.
Regards
Tony Dean
noisebrain wrote:
>
> > What is really needed is a pre-started jvm. When you start up a java
> > process, the jvm will fork, and the child will su to you and proceed as
> > normal. I don't know exactly what the jvm is doing when it is taking
> > all that time starting up so I don't know how useful this would be.
>
> I like this solution, though I don't see the details.
> My guess is that part of the startup time is just that java
> has to uncompress the classes zip file, which is big. The
> scheme above would avoid the uncompress.
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
