On Sat, 2006-05-13 at 22:13 +0200, Niklas Klügel wrote: > > But this just replaces the war on the best kernel with a war on the > > best memory-safe programming language... > > which has my consent. hardware-implemented memory protection > makes sense -for me- in the old days when the only solution to cope > with the related problems was using a dedicated hardware... > Anyway, leaving these aspects aside, i don't see any reasons to > support memory protection in hardware nowadays. > you can track all memory accesses in realtime in software, look at the > jvm - it works and with an acceptable performance.
Consider: 1. The measured performance of the best JVM sucks. 2. There is no possibility of hard real-time in a garbage-collected runtime. 3. The amount of code needed to implement a decent JVM (or similar system) is approximately 10x the amount of code needed to implement a protected microkernel. Next time your life depends on the software being right, which one would you rather depend on? > today the programming languages and > its environments allow a much finer granularity of modularity. You also mentioned sharing. Sharing isn't the solution to robustness. It's the *problem*. Shared-memory concurrency is known to be a completely non-engineerable approach. Finer granularity is not always better. The trick is to discover the finest granularity that real programmers can manage successfully. Unfortunately, there seem to be different answers for program structure (the object boundary) than for protection structure (the subsystem boundary). shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
