This idea is great, I can't imagine what change it would bring in desktop which is always the shortage of java so long .
2009/3/4 Regis <xu.re...@gmail.com> > Sian January wrote: > >> Hi everyone, >> >> Do we want to propose any projects for Google Summer of Code 2009? It >> was quite successful last year for Harmony, with two students >> completing the programme, so definitely worth doing in my opinion. >> >> http://code.google.com/soc/ >> >> Thanks, >> >> Sian >> >> >> Hi, > > I'm thinking about a feature "java daemon", just like "emacs --daemon". > After a jvm is started by "java -daemon", other java applications could > attach to the daemon jvm by "java -attach ...". One deamon java could run > multiple java applications without disturbs, just like running in separated > jvms. We can get some benefits from this: > > * Quick startup > Jvm only start once, we also could use some simple code to initialize the > most used classes. So start app just need load app's own classes, that would > improve user experience, especially on desktop. > > * Smaller footprint > All jvm data structure and bootstrap classes could be shared by all apps. > I'm curious how much memory could be saved if i ran two eclipses in one jvm. > Even more, if app's classes could be also shared? We could say "I want to > share all org.eclipse classes between apps". > > * Saving warming-up time > JIT has enough time to warming-up and compiling methods at the idle time. > Since bootstrap classes are shared, methods in these classes only need to be > compiled once. > > * Sharing data between applications? > I'm not sure this is useful, but maybe the hardest to achieve. > > For students, it's easy to start, maybe a java/native agent could fulfill > the most of requirements, but it's hard to be perfect: total transparency > for apps. Static fields, threads, classloaders, security (is it possible > running Applet and normal java applications in the same jvm?)..., lots of > things need to be considered. > > Any comments/suggestions? > > -- > Best Regards, > Regis. >
