> > You don't want a VM in the kernel, but you might want a system level
> > VM - a single VM used by all java-programs what will do caching and
> > optimalization etc. Other than that, it is interesting to see if
> > there are any new services needed by a VM that the kernel should
> > provide. I know of one such service: user-level exceptions. Being
> > able to handle a memory protection exception without the
> > user->kernel->user context switches makes certain GC/VM-tricks much
> > less expensive.
> >
>
> Hmm... I don't know if you can do that and still maintain OS
> security; anyone remember the "sliding password" security hole?
>
> -hpa
Perhaps you don't need to sacrifice security if you resign from some
futures. I can't see how would it be to have exceptions in the kernel and
probably don't want them there :-). If all of JVM works in the kernel,
using only what kernel can give it (only kernel built-in functions) -
there should be no security flaws IMHO. Of course, you should carefully
chose java code to be run in such JVM.
However, as I explained in other message, the idea is to have a "portable
machine code", that could be inserted into the kernel as the system is
running. The accent is laid on "portability" and parhaps it should not be
named JVM because "compatibility with Java" is not what I mean in this
case. But, using concepts from the already existing solution could give
interesting possibilities in the future in terms of extendablity.
bye
T.
-- ** Tomasz Rola I am going to forward myself to /dev/null ** ** To check if data is really discarded there ** ** Or is it a gate to another Universe... ** ** mailto:rtomek@cis.com.pl , http://www.cis.com.pl **
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html