On 21 Jan 2005 at 18:14, [EMAIL PROTECTED] wrote: > >On 21 Jan 2005 at 15:43, [EMAIL PROTECTED] wrote: > > > >> >[EMAIL PROTECTED] / 05.1.21 / 00:52 PM wrote: > > > >[] > > > >> But I think that if the problem was solely due to an address bug, > >> it would happen more often. And problems with addressing is > >> exactly what can happen during a page fault...(when the working > >> set of pages of a process, which contains addressing information > >> doesn't have enough physical memory...a page fault occurs....it > >> the OS has enough memory to keep the working sets of all processes > >> in physical memory there will be fewer page faults.) Page faults > >> don't occur very often. Only when the system is stressed do they > >> happen more frequently...the same goes for the Overwrite Bug. > > > >A page fault in a working virtual memory subsystem will *never* > >result in the memory tables being corrupted so that pages get mixed > >up. > > But I'm not talking about a working virtual memory subsystem...I'm > talking about a stressed one...
No, a stressed VM is not a non-working one. A stressed VM will be slow. It will cause everything to drag to a crawl. But it will *never* corrupt data. If it does, it's not a working VM subsystem! > . . . a working car still won't run if there > isn't enough gas in it....and it will sputter on fumes. I understand > what you are saying here...but even if the system is a well designed > one..which it is, if resources aren't there, it won't work correctly. Yes, it *will* work correctly. That is defined as: 1. swaps pages in and out as needed, however slowly, and even if it results in thrashing and completely halts for the applications being served by the VM subsystem. 2. maintains 100% data integrity of all the data pages being managed. No matter how much stress you place on a VM subsystem, it will perform these functions. Now, that doesn't mean the applications being served by it will be usable at all, but that's a completely different set of issues. And *that's* the set of issues you're defining as "not working correctly." It's an end user's point of view, not a data point of view. In short, I can state with about 99.99999% certainty that the OS X virtual memory manager is *not* causing corruption of Finale's data. > So if you would, please humor me for a minute. It appears that you > know a great deal about this and can shed some light on the problem > which would be helpful. . . I know a bit about the architecture of operating systems and how virtual memory works. I know nothing specific about OS X, except that it's built by a reputable company that really knows what it's doing and that it is based on a modern OS kernel, one that has incorporated virtual memory management for a long time. > . . . What happens in OS X when there aren't enough > resources to keep all the necessary working sets up and running in > Physical RAM which is where they need to be? . . . As you said, a page fault, which is a form of software interrupt which causes everything in the application space to stop while the VM re-arranges memory to try to give the applications currently requesting new memory pages the resources they need. When it's completed its job, it allows the applications to continue executing, in exactly the same place where it had earlier halted them. > . . . It just doesn't make > sense that it would be business as usual, there would have to be some > fallout from all of this? . . . Page faults due to lack of memory happen *all the time* during the regular operation of every modern operating system. It's only when things are at borderline conditions that the user even notices anything other than, perhaps, a momentary pause (and the sound of the hard drive churning). This is because application execution is *halted* while memory is reconfigured. > . . . And the system doesn't always just quit. . . . It should *never* quit -- that's the whole point of a virtual memory system, which is designed to make it possible to operate as though you have more memory than is physically present for the OS. > I've read in the past about preferences being affected by these sorts > of circumstances. So could it be that other data can also be affected > or even the way that data is being accessed is being affected? Also, > while the OS is UNIX based, it is quite different in many ways. Many > of the differences lie in the way memory is dealt with. Which also > makes me wonder if MM is using Unix programmers to make the transition > or if they have hired people that are OS X programmers. I don't know why preferences would affect virtual memory, unless they are settings that you can use to tweak VM settings. As to Unix, I'm not sure if Apple wrote its own VM for OS X or if the VM OS X uses is adapted from the Unix variant. Given that it's definitely something that is intimately tied up with the basic kernel- level operation of the OS (the VM runs at the highest level of any OS components, which is why it can interrupt lower level operations), I'd suspect it was something that came from the Unix legacy (however much it may have been adapted). None of that makes any difference, though, since a virtual memory subsystem, even a poorly performing one, will never have an effect on data integrity in the application space. Yes, it has a definite effect on performance, but that's an entirely different set of issues. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
