embryo2 wrote:
Schol-R-LEA wrote:
Furthermore, using unpaged memory is not simpler from the perspective of the operating system. Most 'flat' memory modes are really only flat from the perspective of a userland application; any multitasking OS still needs to parse the memory up into multiple process spaces. The paging hardware makes this easier, by allowing non-contiguous memory regions to be mapped to a contiguous virtual space (important when memory is being allocated at runtime), among other things.
In case of paging overall algorithm, that you employ to manage memory, is split between hardware and software parts. In case of "no paging" there's the same algorithm, but without any separated part. So, the complexity is still the same.
I am at a loss to understand what you are saying here. Could you please expand on this point?
embryo2 wrote:
But there's a small part of the algorithm that is implemented in hardware and can be reused by system developer. As a time saver it's just nothing in comparison with the decrease of flexibility you will have, so it's not viable to consider this part at all.
I'm not following you here, either. Where is the loss of flexibility in this?
Just to be clear, I am not seeing this as a matter of relying on a hardware mechanism, but rather using the available hardware to supplement the the default software mechanism. The specification for memory management is that it provide enough memory for each process or raise an error when it cannot, and release memory that is no longer in use at the earliest point it can. So long as it accomplishes this goal, the details of the implementation should be of minimal importance, so how it is implemented on a given hardware platform should reflect what is most efficient for that system. Is paging going to efficient on a given platform? Without profiling some test code and applying cost-benefit analysis, there's no way to know.
embryo2 wrote:
Schol-R-LEA wrote:
It also reduces the computational burden for the OS itself, again by automatically restricting the space of memory that the system needs to be concerned with at a given moment.
I don't understand how it reduces the computational burden.
Perhaps I am wrong in this, but my thought is that it reduces the amount of memory it has to manage at a given point - the memory manager need only concern itself with the memory used by the current process. It can use a smaller, more localized representation of the data map, and has a smaller search space to work in when trying to determine things such as which memory is free for re-allocation.
While these are not advantages specific to paging, the paging system is useful for implementing them.
embryo2 wrote:
Schol-R-LEA wrote:
nor am I convinced that simplicity for the operating system developers is really a wise goal. Providing simplicity for the users and the application developers often requires considerable complexity on the part of the OS implementation.
Simplicity for users won't be given for free. If OS is too complex then users will have a piece of trash instead of something manageable. So, we just must pay attention to the complexity of the OS. And generally it is achieved by creating extensible systems. ]The core should be very simple and then there will be no much problems about extending it.
I am pretty sure this is exactly what I have been saying all along... except that you seem to think I am saying that paging should always be part of the OS. I've never said anything about the core of the OS at all, as that core - or rather, the reference implementation - should have nothing specific to any hardware mechanism. Those are factors for when you are adapting the design to a specific platform, and which works best will depend on the platform - or even the specific machine being used, hence my intention to use Massalin's adaptive code generation techniques.
embryo2 wrote:
Schol-R-LEA wrote:
I gather that you intend to write a single high-level garbage collector that would be used unchanged on all hardware, correct?
My goal is about standard top-down approach. I want to have simple and manageable architecture while all extensions (including hardware related optimizations) will be implemented as manageable parts with simple interaction protocol.
This statement seems a bit vacuous, or at least vague. I can see what you are saying, I think, but it just boils down to you applying basic software design principles. I would be ashamed to admit that I was
not applying these principles to the design of a sizable project, at least not without damn good reason.
Furthermore, without details, these statements are meaningless, as terms such as 'manageable parts' or 'interaction protocol' can mean almost anything. What qualifies as an interaction protocol? That could be anything from a specific JVM bytecode for triggering a system service to a trap or soft interrupt to a simple function call using the standard Intel C calling convention to a system call that triggers loading a particular software module. It is a meaningless statement unless we can grasp what kind of protocol we're talking about.
Finally, people of comparable intelligence can still disagree as to what qualifies as a "simple and manageable architecture' and a 'simple interaction protocol', especially if we're mixing up the users' perspectives with the system developers'. Are UNIX pipes simple? Are MS-DOS style interrupt-vectored system calls simple? Is message-passing method invocation (as used in Smalltalk) simple? I can make arguments both for and against in each of those cases, both from the user or client-programmers perspective and from the OS devs perspective.
embryo2 wrote:
Schol-R-LEA wrote:
My idea is simply to use paging to trigger the garbage collector, and using pages to partition the memory for faster collection cycles.
Let's compare two algorithms - with paging and without it. It's easy to understand how the "no paging" algorithm works, but how paging helps to trigger garbage collector is not clear to me. The basic idea is about to find a way of detecting there's no more free bytes in a page, so, how paging can help the idea? Or there can be another condition that triggers the "copy to new page" procedure, but again - how paging is related to the condition detection?
OK, this may not have been my finest idea, I will admit. My thought was basically that paging is usually triggered when a page not currently in memory is accessed, which often means that one or more pages will have to swapped back out of memory to make space. My idea was when a page is to be paged out, it would force a GC cycle on that page before writing it, meaning that only the live data would be written to the swap storage - and if there is no live data, the page as a whole can simply be freed. It seemed to me like a fair means for amortizing the garbage collection cycles, as well (rather than waiting for the whole arena to get filled), though I haven't actually calculated this. It wouldn't be the only time the memory is reclaimed, of course, but it would mean it was getting triggered at points where memory is likely to be running low.
embryo2 wrote:
Uncontrolled access in managed environment is something unexpected. It can be a bug (as it was mentioned before), but it can't be a result of a normal operation.
Once again, I'm not sure I see what you are saying here... Are you claiming that an 'uncontrolled access in managed environment' can only arise out of a bug in (presumably) the 'managed environment'? That sounds excessively optimistic to me, as it assumes that there will never be any security exploits or hardware transients. If you truly believe that it is possible to write any kind of software that can prevent all unforeseen exploits, and that hardware glitches are either too rare or too unimportant to be addressed, then no rational response can be made to such an unrealistic viewpoint.
embryo2 wrote:
So, it's just about debugging. And for debugging there's the idea of the debug session with many additional hardware features involved (like debug registers or even virtualization). That's why I see no point in the security related paging stuff.
I have no idea what you mean be this. None at all. I'm not sure if I want clarification or not at this point, but since I cannot respond to this without it, well... please, explain further.
The only thing I
think I can get from it is that you see security as something that can be provided in a single software layer, a claim that seems absurd to me. Security is a process, one with several layers, and requires active participation on the parts of the users, application developers, and administrators, as well as the OS developers. No amount of 'managed code' can prevent a user from running a program that he or she has rights to use in a way that compromises their data. 'Managed environments' are at most one line of defense, and not even the most important one at that - the most dangerous security risks do not come from software exploits, but from social engineering tricks that get the user to do what you want, often without writing a line of code. There is no way for any program to prevent a user from giving away information they have legitimate access to, or doing something foolish but permissible with their system if they have the rights needed to perform that action.
Perhaps I am being too 'belt and suspenders' here, but defense in depth seems a no-brainer to me. Assuming that any one mechanism cannot be compromised almost ensures that once it
is compromised, the entire system will be. Your Managed Environment is the software equivalent of the Maginot Line, statically defending the wrong things in the wrong ways and in the wrong places while ignoring the more serious threats elsewhere, and at such a great cost that it undermines the ability to make a more dynamic response once it is bypassed.
While I agree that code management is a valuable set of tools, and unlike Brendan I am not convinced that such runtime checks can always be avoided (though his argument seems less to do with the runtime checks themselves than with whether they should be implicit or explicit - he defines explicit checks as control flow rather than management, which seems a strained objection to me), you seem to be placing far too much emphasis on it, and ignoring those areas where it makes sense to supplement it.
embryo2 wrote:
So, we can trade a few cycle gains for the too constrained architecture that makes the system too complex. What's the best? I vote for the flexibility.
You still haven't explained why this would be less flexible, and I am not certain why it would be. To repeat, I see this as a matter of an implementation detail, not a feature of the OS itself; whether the platform even has hardware memory management or not, and whether it is used or not, IMAO should be a matter of concern for the implementation, not the overall design.
I would like to say that were should agree to disagree and drop this matter for the time being, but I am still not sure if I have understood all your points correctly. Please feel free to elaborate on those points I have said I was confused about, but at this point I think it best if I move on to more productive issues once you have done so.