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!
O.K...I'm with you...I understand. There may have been a misunderstanding here...when I suggested that data may be getting corrupted... I may not have been able to clearly articulate that I never meant the OS and it's VM subsystem was doing the corrupting...just that something was going haywire with Finale at this point. Not by any fault of the OS but rather because of the state the OS was in...yes still working the way it was supposed to and the way it was designed to. But sluggish and/or thrashing.
. . . 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.
O.K....I understand what you are saying...and I'm still with you. :-)
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.
Yes, very well put...probably better than I was able to put it but this is what I'm getting at. Thank you!
My theory is that at this point, there is a problem with the way Finale has been programmed. A problem, which results in the Overwrite Bug, that when there is more memory in a machine, doesn't occur. But when there isn't enough memory and the system gets to the point of thrashing, then the mistakes made in the way that Finale was written result in this problem.
Can you think of anything in the way a program is coded that would fit into this scenario and possibly cause the overwrite bug? Problems with the way the program uses threads? I/O issues? Caching? etc....?
I'm doing my best to guess at causes because I always have a desire to get an explanation that works for a given problem. But you have a good understanding of what is going on under the hood and you are also very good at articulating these things. So if you have any ideas, I'd love to hear about them!! :-)
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.
Again, agreed.
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 affectedor 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.
Not the preferences affecting virtual memory, but depending on the way an application is programmed as to when and how it accesses it's preferences...if there has been a system slowdown due to a RAM shortage, the preferences will appear to have not been saved or will revert to dafault either partially or fully.
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).
I believe it is an adaptation based on FreeBSD 5 and the Mach kernel and I believe that there are some things VM that are uniquely Apple. Things that a programmer would have to be mindful of. Even if they are capable Unix programmers, Apple lays out very specific guidelines on how to make things run correctly in OS X.
We may never have clear answers to what is going on because as Hiro said, only the programmers know for sure what is going on. And I doubt MM would volunteer any information on these things anyway.
Thanks again in advance David...:-)
-K -- _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
