P3
>>>> The following is copied from http://j2se.sfbay.sun.com/web/bin/view/Hotspot/MVMArgs written by Karen Kinnear.
Right now there is a protocol whereby when you start java with the -XUseMServer flag it talks to an existing MServer (started by java -XRunMServer listening on a default port) to try to start a task with the passed-in arguments.
There are arguments that could be requested that would not be compatible with the
existing ones running in the MServer.
One goal here is to cleanly return failure and reason for failure to the requestor.
My thinking is that there are several categories of errors. An initial set (without
having made a full table of possibilities) would include:
1. this MServer is out of resources, but this would still qualify for another or a new MServer
2. this request isn't supported in multitasking mode
3. these arguments don't match with the existing MServer args, but might with another one
(maybe a subset of #1)
4. rejected for native code -> must kick off stand alone java
5. This argument is not meaningful for -XUseMServer, but we want to ignore it and keep running, potentially logging the information as a warning.
Another goal is to look into possible recovery mechanisms.
For future for plug-in for instance, I would expect the plug-in to try an existing MServer and if it did not work try/launch another one, or kick off a standalone java for the particular process.
Again, I think the plug-in/webstart folks have explored some dimensions of this problem already, specifically which command-line args can currently be used in a running java, so I would recommend starting by gathering that information and seeing what is different here.
Right now there is a protocol whereby when you start java with the -XUseMServer flag it talks to an existing MServer (started by java -XRunMServer listening on a default port) to try to start a task with the passed-in arguments.
There are arguments that could be requested that would not be compatible with the
existing ones running in the MServer.
One goal here is to cleanly return failure and reason for failure to the requestor.
My thinking is that there are several categories of errors. An initial set (without
having made a full table of possibilities) would include:
1. this MServer is out of resources, but this would still qualify for another or a new MServer
2. this request isn't supported in multitasking mode
3. these arguments don't match with the existing MServer args, but might with another one
(maybe a subset of #1)
4. rejected for native code -> must kick off stand alone java
5. This argument is not meaningful for -XUseMServer, but we want to ignore it and keep running, potentially logging the information as a warning.
Another goal is to look into possible recovery mechanisms.
For future for plug-in for instance, I would expect the plug-in to try an existing MServer and if it did not work try/launch another one, or kick off a standalone java for the particular process.
Again, I think the plug-in/webstart folks have explored some dimensions of this problem already, specifically which command-line args can currently be used in a running java, so I would recommend starting by gathering that information and seeing what is different here.