OSDev.org

• Privilege levels: Since all the code that is executed on the system is generated by the JIT-Compiler (which is trusted), all the code can be considered trusted, thus executing it at ring0. A system call needs no ring transition any more.
• Memory Management: When you involve a copying garbage collector (that every application uses), additional memory optimization at runtime can be done. Also, this garbage collector could take care of swapping (writing an unused object to disk and reuse its memory), swapping takes place at object level rather than page level, thus the need for an mmu would disappear. It remains to be seen however, whether the mmu could still be used to improve performance (dirty bit to determine how often a memory region is used...).
• Runtime optimization: In traditional natively compiled code, any optimization has to take place at compile time. When code must be compiled seperately for portability or manageability reasons (driver <-> kernel <-> syscall-library <-> app <-> utility-lib), it must be linked seperately. When the native code is generated at load time by the JIT-Compiler, any optimization can be carried out there, the code could be profiled at run-time and recompiled with different settings to achieve the best results. As a side effect, the code will also be architecture independent ;D. Note that optimization also covers inlining of procedures, which is then possible for functions that reside in a different library, or even in the kernel (when there still is a construct like a kernel).
• Usage of privileged instructions: For very short critical sections, the JIT-Compiler could simply disable interrupts to prevent concurrent access to a memory location/device, instead of acquiring a lock.

• You will eventually run out of physical memory, so swapping to disk is still a good idea. Paging is the fastest and most efficient way to do that IMO.
• Even if you don't run out of physical memory, if you're on a 32-bit system you will eventually run out of address space. This might not be as much of a problem on 64-bit systems, but if you use paging and multiple addresses spaces you definitely won't run out.

• If you have only one GC in the system and it manages all memory for all applications, then individual collections will take longer.
• Generational GCs won't work very well in such a system because the system-wide memory usage patterns will be more "noisy" than they would be on a per-application basis.
• If the GC is allowed to vary per-application, then it can be optimized for that application (e.g. -- ASP.NET has its own GC that is tuned for web apps and web services; the .NET Compact Framework has its own GC, etc.).

AR wrote: JIT alleviates this to a certain extent but it still requires rather pointless runtime interpretation, the results will generally always be the same on a particular CPU anyway (The .Net libraries themselves are compiled during the install process for example).

Architecture independance is about the only real advantage of byte code, but then why not just distribute the raw source code and compile that, it's more or less the same (and actually better since the higher up you are, the more interconnections you can see and the better the optimizations can be).

You also cannot abolish locks for the simple reason that locks aren't used as often in single CPU mode. Locks are needed primarily in multi-CPU mode where disabling interrupts won't stop the other CPUs from running over you.

AR wrote:Architecture independance is about the only real advantage of byte code, but then why not just distribute the raw source code and compile that, it's more or less the same (and actually better since the higher up you are, the more interconnections you can see and the better the optimizations can be).

AR wrote: As far as I can see bytecode offers no advantages in "correctness", you have as much chance of determining that as with raw machine code.

@Joe: Well, I have to agree with brendan, I think swapping using paging will still be more efficient. The biggest issue is that you would have to check for yourself on every access to an object if it is swapped out, unless I'm missing something very obvious here.

AR wrote: As far as I can see bytecode offers no advantages in "correctness", you have as much chance of determining that as with raw machine code. The thing people never seem to understand is that machine code is bytecode, the CPU interprets the bytecode and performs the operation. Essentially the VM just creates a virtual CPU that does the same thing as the real CPU but is 100s of times slower

Well, I have to agree with brendan, I think swapping using paging will still be more efficient.

Legend wrote: Another thing, where I'm very doubtful (not about the design but garbage collectors in general) is the stop & copy collector. Not only does a copying garbage collector halt the vm, I'm really sceptical if the overhead of copying things around in memory is not probably higher then what you could save on allocating. On the other hand, they seem to be very much liked, but I didn't get it really till now.

Colonel Kernel wrote:

AR wrote:

Well, I have to agree with brendan, I think swapping using paging will still be more efficient.

LOL... Now all of Brendan's vast knowledge is being attributed to me? I feel honoured. ;D Or is it the other way around...?

Err, I'm sorry if I messed someting up there. Was already a bit late at night here!

NotTheCHEAT wrote: Much easier, and even faster that way. Trying to write an interpreted OS sounds really stupid. You folks are too lazy to write good old low-level code, or what?

NotTheCHEAT wrote: It can't be done and it won't work. You'll always need to write some parts of the OS in assembly, and assembly and Java/C++ are like polar opposites.

A JIT compiler makes it faster, yes, but then what's the whole point of that? Why not use the outpt from the JIT compiler for the kernel ALWAYS, instead of recompiling it each time you boot?

Trying to write an interpreted OS sounds really stupid. You folks are too lazy to write good old low-level code, or what?