Oracle has developed a virtualized JVM for their various web products.
It puts all the shared, read-only stuff in one layer and all the private
read-write stuff in another layer. It allows each client session to
have effectively their own private JVM with something like 20KB overhead
per session. This seems to me a very promising way of having multiple
independent JVMs on the same machine. Solves the nastly little gotchas
involved in sharing a JVM by giving you your very own JVM.
Anders Lindbäck wrote:
>> 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.
>>
>
> It is also all the time needed to create the objects in the initial
> environemnt from the classes in the zip file.
>
> Tony Dean skrev:
>
>> 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´t wont help much since a large part are the classes in the zip file.
>
> The way to fix that is if classes is in shared memory.
> Think of a deamon which has a prestarted JVM with thr base classes
> in read-only shared memory so all application could share them.
>
> The deamon could run as root and whenever a user wants to start a new JVM
> instead of creating a new JVM the java script will send of a request
> to the deamon. The deamon forks off a JVM with correct parameters and
> set up to run under that users environment.
>
> It´s a prestarted JVM but requires some rewrite of how one can create
> JVMs.
>
> This deamon will in some ways work likea a kernel when it creates processes.
> There are some xecurity problems if anyone may load new classes into the JVM
> but that can be solved in the same way as the sandbox moden in a web browser.
>
> This would speed up JVM start time and also lower the memory requiremsnt
> when running JVM in different processes.
>
> Anders
>
>
> ----------------------------------------------------------------------
> 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]
