OSDev.org

I've been speculating on this concept for awhile. The core principles are that tasks don't actually run within confined limits of memory, but are rather broken up into fragments of code that the kernel constantly manages and patches. Ideally this would rid the requirement for dynamically loaded libraries, and other complexities, but itself would pose some situations.

Consider from the perspective of a single operating task, the kernel would have no requirement to split the process up into fragments of code. Since there would be no requirement to do so. From the perspective of two operating tasks, it might very well require no fragmentation as well, unless the kernel infers at some point both tasks share a common set of instructions. This is where my idea comes into play.

Assume application A and application B both implement functionality that matches semantics of the following C program:
(which happens to be a compare function for qsort)
This can be represented as the following in x86_64 assembly (this assumes the x86_64 calling convention in the SYSv ABI)

Lets bang a bytecount now:

• mov - both operands registers, one access = three bytes proof: 0x48, 0x8B, 0x02
• sub - both operands registers, one accessg = three bytes proof: 0x48, 0x2B, 0x01
• retq - single byte

So ideally we have eight bytes here, for both programs running, that is duplication of the same eight bytes. Which not only wastes addressing space, but also pollutes cache locality in tightly coupled situations. What if the kernels scheduler not only did preemptive multitasking, but made it a requirement to occasionally scan application memory of running tasks, and "about to be executed programs" to strip duplicated chunks of code and patch them conditionally with indirect calls / or long jumps.

Now I understand there is tons of issues within respect to this generalization. For the sake of argument lets assume the kernel had to perform semantic checks to ensure operation was correct and equal. There is still other things that could break this, mainly position dependent code, which for the sake of argument the kernel would also have to check. I'm sure there are tons of others but those are merely politics

But this process would essentially remove the requirement for the following things:
(and quite possibly a few other things)

• Dynamic linking
• System calls
• Binary compatibility

Of course I'm probably crazy, isn't that what we all are though ? What do you think?

graphitemaster wrote:So ideally we have eight bytes here, for both programs running, that is duplication of the same eight bytes. Which not only wastes addressing space, but also pollutes cache locality in tightly coupled situations. What if the kernels scheduler not only did preemptive multitasking, but made it a requirement to occasionally scan application memory of running tasks, and "about to be executed programs" to strip duplicated chunks of code and patch them conditionally with indirect calls / or long jumps.

jumps are expensive too, and in the end the actual code must be in the same address space(or mapped into the current address space) for the cpu to execute it.

graphitemaster wrote:But this process would essentially remove the requirement for the following things:
(and quite possibly a few other things)

• Dynamic linking
• System calls
• Binary compatibility

At lease some part of the above cannot be removed since:
1. Dynamic linking include things that has not been loaded previously.
2. system calls include the change in ring.
3. I'm not so sure.