Again, the main question is which target you are trying to hit. Are you aiming at Java web hosting where a hosting service would offer Java to *all* their customers?
Are you aiming at Java web hosting for any (or nearly any) existing Java web application? In the first case you are aiming at the niche where PHP has found great success. On a purely theoretical level, PHP as a solution should not exist. On a practical level, there are all sorts of reasons why (at present) Java is a PITA for web hosting services, and PHP is easy to accomodate. In this problem domain the vast majority of sites are very low usage. In the second case you are aiming at a much smaller niche. Playing games to keep a pool of JVMs with per-user-application in-memory state makes sense. This is almost certainly going to translate to greater trouble and complexity for the hosting service. More trouble means a higher priced service offered less often. If your aim to make Java ubiquitous (which I believe possible) then you want to target the first case. For low-traffic websites the probability of a GC during the process of a single request is low. Also - though I can't say I've looked at the latest GC implementations in detail, the trend (starting with generational GC) in algorithms was to not move long-lived stuff around. Taken together, it is reasonable to assume that GC is not going to have much (or any) impact. This is aiming at the niche where PHP is popular - a rather large niche. What you are looking for is the simplest thing that can possibly work. You don't need JVM enhancements. You don't need to add complexity in terms of managing pools (always fun). You don't need to worry about leaky abstractions. Odds are you end up with something simple and dead reliable for a hosting service to deploy. On 4/8/06, Darryl Miles < [EMAIL PROTECTED]> wrote: > > Interesting discussion. > > > Ideas? Yes, and it's very simple - use fork()! > > > The problem with fork() in the way you propose is Garbage Collection. A > JVM can move objects and compact heap space during GC, this presents a > problem that moving data unshare's that page. For a native executable > Copy-on-Write provides an improvement on resource usage as memory > allocation is static once allocated, but between two long running JVMs > trying to share pages its not so attractive. > > The other problem of course is the amount of work a JVM does to load > byte code, interpret it and ultimately optimize/compile it into machine > code. This has additional memory overhead a native executable just does > not have. The only thing in the data segment of the address space is data. > > With linux (maybe others) the native program (and shared libs) is demand > page loaded from the EXE file on the system, the OS can just drop little > used code pages knowing it can reload them from a file. While the > concept is partially possible with a JVM its just not done. > > Any solution on this level is only going to be possible through major > enhancements at the JVM level against what traditionally Java has been > about. ByteCode and GarbageCollection really inhibit traditional > approaches to the problem, maybe the GCJ project in the not to distant > will be a faster moving more innovative vehicle for a Java like language > than Sun Microsystems. > > > So from that standpoint of throwing away ByteCode for CompiledCode, the > dynamics of your multiple JVMs become much more like a traditional EXEs. > > I would envisage an ideal solution not too different from what you are > saying. Java code compiled into fully native code and stored on disk, > you can then properly share the classes as nature intended between > multiple JVMs. Then exactly as you say you have a master JVM in control > and could dynamically put web-apps into other JVM processes which could > each dynamically tune their thread and memory usage (on the fly) and as > a last resort shut down the process to cut it away when its been bad, > without disrupting the container environment as a whole. This leads on > to pooling JVMs to recycle the process to walk around memory leak > problems. > > With your problem web-app you could make sure he always got his own JVM > to run in, for the nicer web-apps you could put more than one into a > slave JVM. You could make use of shared mapped pages between processes > and file descriptor passing to hand off incoming connections. There is > no reason the above can't be implemented on both Win32 and Linux in due > course. > > There are no new ideas here. > > Darryl > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
