Page 4 of 5
Re: Will the MMU become the next redundant HW block?
Posted: Sat Aug 25, 2012 6:11 pm
by Brendan
Hi,
OSwhatever wrote:Brendan wrote:To me, the biggest problem with IPC is changing from one process' "working set" to another process' "working set" - e.g. fetching cache lines for the second process and flushing (and if modified, writing) cache lines used by the previous process to make room. Paging does make the cost of this "working set switch" a little higher, but "single address space managed code" doesn't avoid it. Given that the cost of a "working set switch" can't be avoided, my approach is to minimise the number of "working set switches". Basically, when message/s are sent they're just put in a FIFO queue so that any "working set switches" can be postponed - e.g. you can send 100 messages and do one "working set switch" rather than doing 100 of these "working set switches".
Now, putting a reference into a FIFO queue is fast, and it doesn't matter much what this reference is. It could be the address of the message data, or it could be the address of a page or page table that contains the message data. Managed code would make little difference.
With multiple address spaces you never get rid of the copying messages from one address space to another though, unless you send entire pages.
I either copy the data (small messages), move entire pages (medium messages) or move a page table (large messages, up to 2 MiB).
For my scheme, actually moving the message data (from sender's address space to FIFO, and eventually from FIFO to receiver's address space) isn't really a problem. The main bottleneck is memory management (allocating pages in the message buffer when creating new messages; and freeing pages in the message buffer when they're no longer needed).
I'm not saying my method is the fastest way (using shared memory would be faster). I like it for other reasons - "
messages disappear when sent and appear when received" is a much cleaner concept for application developers to deal with (especially for distributed systems), and it's incredibly difficult for an application developer to screw it up.
Cheers,
Brendan
Re: Will the MMU become the next redundant HW block?
Posted: Wed Aug 29, 2012 12:52 pm
by qw
OSwhatever wrote:As I see it, the fundamental change is the protection granularity, you go from protection on process level to protection to object level. There is very little HW support for object protection so it must be handled by SW.
This remark in the original post drew my attention. Does hardware support object protection? Hows does/would that work? Just being curious...
Re: Will the MMU become the next redundant HW block?
Posted: Wed Aug 29, 2012 7:46 pm
by linguofreak
Hobbes wrote:OSwhatever wrote:As I see it, the fundamental change is the protection granularity, you go from protection on process level to protection to object level. There is very little HW support for object protection so it must be handled by SW.
This remark in the original post drew my attention. Does hardware support object protection? Hows does/would that work? Just being curious...
There have been, in the past, designs that tried it. They didn't do very well. See, for example:
http://en.wikipedia.org/wiki/Intel_iAPX_432
Re: Will the MMU become the next redundant HW block?
Posted: Thu Aug 30, 2012 6:11 am
by OSwhatever
Thanks, I didn't know about this CPU which seems to be before its time. It's about this type of architecture I would have in mind if object protection would be implemented in HW, basically descriptors.
iAPX 432 systems were expensive and very slow.
I guess this is a bad thing when you try to sell them.............
However, now with the process technology greatly improved this type of processor could easily fit on a SoC.
Object protection would be the natural way to solve protection, I would have proposed it if I was a CPU designer. I don't know where the idea with a page table comes from and I would never have thought about it as it seems far fetched. The page table has some advantages but many can be solved in other ways.
Re: Will the MMU become the next redundant HW block?
Posted: Sun Sep 02, 2012 7:11 am
by Owen
OSwhatever wrote:Object protection would be the natural way to solve protection, I would have proposed it if I was a CPU designer. I don't know where the idea with a page table comes from and I would never have thought about it as it seems far fetched. The page table has some advantages but many can be solved in other ways.
The page table falls out of virtual memory (hardware likes tables. They're easy to access; though you see different designs, e.g. PowerPC's hash table which essentially is an extension of the TLB). Virtual memory falls out of asking the question "How do I make this machine behave, from a program's point of view, like multiple isolated machines". That question falls out of Unix fork/exec, which initially worked by swapping out the whole contents of RAM to disk
Re: Will the MMU become the next redundant HW block?
Posted: Mon Sep 03, 2012 4:59 am
by qw
I guess on the x86, one could use segmentation for object protection. Of course it has its limitations (not to mention bad performance) but it is possible through the LDT to grant each process access to a limited set of objects.
Never heard of the 432 before.
Re: Will the MMU become the next redundant HW block?
Posted: Tue Sep 04, 2012 8:36 am
by Nable
> I guess on the x86, one could use segmentation for object protection.
I also like this idea very much but it's a way to rdos.
And object protection is smth more complex than just bounds checking and/or read/write protecion of the whole object (because some class members may be read-only and others are not, then some of them may be public and others are private).
After all, managed execution with JIT seems the best way, although some CPU-side support is required to achieve speed.
This link may be interesting:
http://en.wikipedia.org/wiki/BiiN (that page contains links to more CPUs with some OOP support)
Re: Will the MMU become the next redundant HW block?
Posted: Tue Sep 04, 2012 12:21 pm
by bluemoon
If there is object level protection, I would like to have ACL(or friend class checking) instead of plain read-write-exec. Am I asking too much?
Re: Will the MMU become the next redundant HW block?
Posted: Wed Sep 19, 2012 4:44 am
by trinopoty
First, we must understand what is exactly meant by managed language.
Managed language is equivalent to an unmanaged language when its runtime library is removed.
The runtime saves the programmer from managing low level aspects of memory directly. But since an operating system will require to manage memory at extremely low levels, a managed language won't be applicable.
As for the benefits of managed language; it provides a lot of protection(assuming that the vm is perfect). I cannot see why the protection cannot be implemented in MMU. Taking all the facts into consideration; I think that MMU will continue to exist forever in one form or another; and that a managed language is a managed language only because of its runtime. There is no reason why a native code cannot run as managed code; you only need a special runtime and MMU.
Re: Will the MMU become the next redundant HW block?
Posted: Wed Sep 19, 2012 8:42 am
by bluemoon
Managed language is equivalent to an unmanaged language when its runtime library is removed.
I disagree. Managed language is
undefined when its required runtime is removed.
A managed language is a managed language only because of it is
being managed, and irrelevant to runtime.
How it is run,with or without runtime is not important, it can even be interpreted.
(but a runtime is almost necessary for a complex language anyway)
And by the way, some protection can be done by syntax / bound checking when compile.
Re: Will the MMU become the next redundant HW block?
Posted: Thu Sep 20, 2012 2:44 am
by qw
Well, what an MMU does is test things like: is the page present, is the page readable/writable/executable (as requested) and does the page belong to the requesting process? In a managed environment, the same may be done by software.
Re: Will the MMU become the next redundant HW block?
Posted: Thu Sep 20, 2012 2:56 am
by Combuster
But software has a hard time doing that as asynchronous and as fast as dedicated silicon can. Which brings us back to all the other arguments that have been posted so far.
Re: Will the MMU become the next redundant HW block?
Posted: Thu Sep 20, 2012 6:57 am
by trinopoty
Combuster wrote:But software has a hard time doing that as asynchronous and as fast as dedicated silicon can.
And that is why MMU will always continue to exist as dedicated hardware.
Re: Will the MMU become the next redundant HW block?
Posted: Thu Sep 20, 2012 7:09 am
by OSwhatever
trinopoty wrote:Combuster wrote:But software has a hard time doing that as asynchronous and as fast as dedicated silicon can.
And that is why MMU will always continue to exist as dedicated hardware.
MIPS has only a TLB and uses a software approach for the actual page table. Page table walker are quite large compared to the rest of the logic of a CPU excluding the caches and MIPS usually have a smaller footprint than their ARM equivalents.
I'm more concerned how page tables scale with larger memories. In the future we will have terabytes of internal RAM memory and the question is if the page table is going to be a bottleneck as it would require something like 5 page table levels. They already tried with the inverted page table but it has other drawbacks.
I think per object protection could be an interesting approach in the future even if I'm skeptical if the MMU will disappear completely. MMU is still needed for virtualization, however if we could increase the page size to megabytes, the page table would be much smaller.
Re: Will the MMU become the next redundant HW block?
Posted: Thu Sep 20, 2012 7:38 am
by bluemoon
OSwhatever wrote:I'm more concerned how page tables scale with larger memories. In the future we will have terabytes of internal RAM memory and the question is if the page table is going to be a bottleneck as it would require something like 5 page table levels. They already tried with the inverted page table but it has other drawbacks.
Perhaps the amount of memory
visible to a core (or group of cores in order to support multi-threaded process) is set to a fair limit, and greatly increase the number of core. ie. each piece of memory is exclusive to specific core / core group, and provide some memory-mapped-io for inter-cpu communications.
This way the page table can be keep small.