1. Mac Os X Memory Management App Download
2. Mac Os X Download
3. Mac App Memory
4. Mac Os Memory

May 19, 2005  1. Having things in inactive memory is to your advantage. OS X is predicting that your next request for instructions is likely to come from certain recently accessed instructions. There is no problem in having a low amount of free memory in OS X. OS X has stored many instructions in RAM (in its file system buffer cache) and in inactive memory. Apr 23, 2013  About the Virtual Memory System. Efficient memory management is an important aspect of writing high performance code in both OS X and iOS. Minimizing memory usage not only decreases your application’s memory footprint, it can also reduce the amount of CPU time it consumes. May 26, 2020  Choose Apple menu About This Mac, then click Storage. Each segment of the bar is an estimate of the storage space used by a category of files. Move your pointer over each segment for more detail. Click the Manage button to open the Storage Management window, pictured below. This button is available only in macOS Sierra or later. But running a search for 'RAM' on the Mac App Store will bring up a number of options. Remember to check the reviews to find something reputable. Read next: How to find the best apps on the Mac. Historically, the Mac OS used a form of memory management that has fallen out of favour in modern systems. Criticism of this approach was one of the key areas addressed by the change to Mac OS X. The original problem for the designers of the Macintosh was how to make optimum use of the 128 kB of RAM that the machine was equipped with.

Untitled[edit]

I apologize if my English isn't perfect, anyway, I think is at least understandable.Motorola MC68000 isn't a 'full 32-bit' processor; it has only 24-bit wide address bus.It is incorrect to say '24 lines allow addressing up to 8MB' because 24 lines allow to address up to 16 MBytes of memory (any kind of course). The reason of the 8MBytes limit is due the way the memory map was structured on '24-bit' Macs (http://www.osdata.com/system/physical/memmap.htm#MacPlus).Because of this MacOS 7 is able to address more than 8 MBytes of memory (4MBytes RAM + 4MBytes ROM) only on the models equipped with 'full 32-bit' processors.I know my english is simple. Please feel free to improve it in any way.Please let me know (here) if anybody of you think I'm wrong somehow.- 213.203.155.204 18:04, 1 January 2006 (UTC)

The tone of the article worries me slightly..the author(s) seem to assume that Apple refused to change the memory manager out of pure stubbornness or pig-headedness. I think it more likely that Apple assumed all along that some radically new OS would supercede the existing Mac OS (as OS X eventually did) and that it would not be worth the trouble to rewrite the entrenched memory manager. -Astrovan

Some developers were already indicating their displeasure at the way memory management worked as far back as 1989 or so (possibly earlier, but that's when I became aware of it). At that time System 7 hadn't even been released, and it certainly didn't address the issue. In fact by making MultiFinder a non-optional part of the system, it made the situation worse. There were some third-party extensions that replaced the memory manager (Optimem), which showed that it could be changed - though it's true that Optimem caused some compatibility issues with some apps - but then they didn't have the inside story that Apple themselves would have had. In 1992 some colleagues and I had a lengthy discussion with some Apple engineers at a developer seminar about the situation, and we outlined a scheme to them that we thought could have worked. They agreed it was a workable idea, but told us that backward compatibility would be too difficut to ensure, though we didn't really buy that, since our plan provided an identical view of the system from the app's perspective. Perhaps they knew that it really wasn't apps they were worried about, it was system code that was taking liberties - it's come to light much more recently that a lot of it was undocumented, uncommented and certainly unmanaged. However, despite this their tone was very much along the lines of 'you boys shouldn't meddle in grown-up's business, now go away and leave it to us, we know what we're doing'. We found it patronising to say the least, especially as clearly the implementation that the 'grown ups' had come up with sucked so badly. OS X totally replaces the memory manager though implements the same APIs in Carbon, so it shows that a different plan could have been dropped in underneath without compromising API compatibility - and provided apps stuck to the rules that Apple had promoted since the first public issue of Inside Macintosh, they would not have had a problem. Apple's other sticking plaster 'solutions' to the problem - temporary memory and so forth, as well as the seriously crappy virtual memory scheme in System 7.whatever, simply added to the problem in spades. It's a moot point, but they really should have bitten the bullet and fixed it with System 7, even if there would have been some bumps in the road as a result - they did it with the 24 -> 32 bit thing, 68k -> PowerPC thing, and others, so why they were so stubborn about this is hard to fathom.Graham 08:00, 5 Sep 2004 (UTC)

I agree with the points made by Graham, however, I do believe that the article does not contain a level of objectivity that is desirable. While Graham makes perfectly valid points, they are still points of personal opinion, which could be done without. If this article was more objective, then perhaps it would not seem to people that Apple was 'stubborn or pig-headed'. For instance, instead of saying 'Apple did a bad thing' we could say 'It was some people's opinion that Apple did a bad thing', the latter keeping a neutral point of view. This would be quite an interesting (and by that I mean 'boring') task to do, but it would give this article quite a nice polish. --huwr 08:51, 6 Sep 2004 (UTC)

I am deleting this:

In fact this demonstrates conclusively that it was possible to change the model all along without a major compatibility issue, which was always Apple's defence for keeping the original scheme.

because it is, pardon me, bullsh*t. The 'compatibility issue' was that applications were reaching into private memory manager data structures, patching traps (in many cases, Apple could not change the order in which purely internal routines were called by portions of the toolbox without breaking important third-party applications), directly reading low-memory globals, in other words, generally violating encapsulation. This was a problem for the entire Mac toolbox, not just the memory manager.

All of that compatibility nightmare still exists -- in the Mac OS 9 emulation layer (Classic.app).

In Carbon on Mac OS X, Apple could do away with all the cruft because there is no binary compatibility with old applications. Carbon apps may run on Mac OS 9 -- but the version of Carbon on Mac OS 9 is a compatibility shim that still uses the old implementation underneath the modernized API calls. Only in Mac OS X could Apple fully do away with the old implementation.

(If you must have credentials, I was a software engineer on the Carbon team at Apple.) —Preceding unsigned comment added by 213.203.155.204 (talk • contribs) 19:04, 1 January 2006 (UTC)

I think that's fair comment. But since Apple were already aware that there was a problem as far back as the late 80s, there is no real reason that Carbon or so0mething very like it could not have been instigated then, rather than waiting for OS X (and which, I seem to recall, was forced on them by some high-profile rebellious developers who refused point-blank, and quite reasonably, to port their code to Cocoa). Adoption might have been slower since there was no clear benefit in the short term, but Apple could have done it. I think that's the point. Graham 03:44, 2 January 2006 (UTC)

That's not really the topic of the article, though. Your meeting with Apple engineers of course isn't usable in the article because of WP:Verifiability. It's clear that everyone was annoyed by MultiFinder and the lame memory scheme we all found ourselves in; if you feel the need to add citations saying so then feel free. More citation would help this article, though it's hard to find them on programming topics from the 80s and early 90s. Tempshill 23:07, 8 March 2006 (UTC)

Fair use rationale for Image:Mac OS Classic application memory allocation.png[edit]

Image:Mac OS Classic application memory allocation.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 07:01, 1 January 2008 (UTC)

Historic or current article[edit]

Does this article reflect the current state or is it a historic article about pre OS X era? If so it should be renamed IMHO. —Preceding unsigned comment added by 217.110.199.118 (talk) 10:18, 28 August 2009 (UTC)

This article is definitely not up to date. There is no description of the 64 bit system used today Agnerf (talk) 05:22, 18 August 2019 (UTC)

Renamed it because it is fundamentally historic. Contemporary macOS memory management methods are not particularly distinctive. On the whole, not hugely different from any other Unix-like operating system. Only Classic Mac OS has such a unique way of managing memory that it deserves its own article in my opinion. (But, if someone disagrees, and thinks such an article should be written about contemporary macOS, by all means go ahead in another article.) SJK (talk) 08:38, 1 January 2020 (UTC)

'32-bit clean' redirect[edit]

32-bit clean redirects here, but there's a similar phenomenon in the ARM architecture and System/360 which also had programs use unused address bits to store data which caused problems when addresses were expanded. — Preceding unsigned comment added by 206.21.52.10 (talk) 07:15, 7 February 2013 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified one external link on Mac OS memory management. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100516140618/http://www.memorymanagement.org/articles/mac.html to http://www.memorymanagement.org/articles/mac.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, 'External links modified' talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these 'External links modified' talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}}(last update: 15 July 2018).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot(Report bug) 07:36, 11 January 2018 (UTC)

Efficient memory management is an important aspect of writing high performance code in both OS X and iOS. Minimizing memory usage not only decreases your application’s memory footprint, it can also reduce the amount of CPU time it consumes. In order to properly tune your code though, you need to understand something about how the underlying system manages memory.

Both OS X and iOS include a fully-integrated virtual memory system that you cannot turn off; it is always on. Both systems also provide up to 4 gigabytes of addressable space per 32-bit process. In addition, OS X provides approximately 18 exabytes of addressable space for 64-bit processes. Even for computers that have 4 or more gigabytes of RAM available, the system rarely dedicates this much RAM to a single process.

To give processes access to their entire 4 gigabyte or 18 exabyte address space, OS X uses the hard disk to hold data that is not currently in use. As memory gets full, sections of memory that are not being used are written to disk to make room for data that is needed now. The portion of the disk that stores the unused data is known as the backing store because it provides the backup storage for main memory.

Although OS X supports a backing store, iOS does not. In iPhone applications, read-only data that is already on the disk (such as code pages) is simply removed from memory and reloaded from disk as needed. Writable data is never removed from memory by the operating system. Instead, if the amount of free memory drops below a certain threshold, the system asks the running applications to free up memory voluntarily to make room for new data. Applications that fail to free up enough memory are terminated.

Note: Unlike most UNIX-based operating systems, OS X does not use a preallocated disk partition for the backing store. Instead, it uses all of the available space on the machine’s boot partition.

The following sections introduce terminology and provide a brief overview of the virtual memory system used in both OS X and iOS. For more detailed information on how the virtual memory system works, see Kernel Programming Guide.

About Virtual Memory

Virtual memory allows an operating system to escape the limitations of physical RAM. The virtual memory manager creates a logical address space (or “virtual” address space) for each process and divides it up into uniformly-sized chunks of memory called pages. The processor and its memory management unit (MMU) maintain a page table to map pages in the program’s logical address space to hardware addresses in the computer’s RAM. When a program’s code accesses an address in memory, the MMU uses the page table to translate the specified logical address into the actual hardware memory address. This translation occurs automatically and is transparent to the running application.

As far as a program is concerned, addresses in its logical address space are always available. However, if an application accesses an address on a memory page that is not currently in physical RAM, a page fault occurs. When that happens, the virtual memory system invokes a special page-fault handler to respond to the fault immediately. The page-fault handler stops the currently executing code, locates a free page of physical memory, loads the page containing the needed data from disk, updates the page table, and then returns control to the program’s code, which can then access the memory address normally. This process is known as paging.

If there are no free pages available in physical memory, the handler must first release an existing page to make room for the new page. How the system release pages depends on the platform. In OS X, the virtual memory system often writes pages to the backing store. The backing store is a disk-based repository containing a copy of the memory pages used by a given process. Moving data from physical memory to the backing store is called paging out (or “swapping out”); moving data from the backing store back in to physical memory is called paging in (or “swapping in”). In iOS, there is no backing store and so pages are are never paged out to disk, but read-only pages are still be paged in from disk as needed.

In OS X and in earlier versions of iOS, the size of a page is 4 kilobytes. In later versions of iOS, A7- and A8-based systems expose 16-kilobyte pages to the 64-bit userspace backed by 4-kilobyte physical pages, while A9 systems expose 16-kilobyte pages backed by 16-kilobyte physical pages. These sizes determine how many kilobytes the system reads from disk when a page fault occurs. Disk thrashing can occur when the system spends a disproportionate amount of time handling page faults and reading and writing pages, rather than executing code for a program.

Paging of any kind, and disk thrashing in particular, affects performance negatively because it forces the system to spend a lot of time reading and writing to disk. Reading a page in from the backing store takes a significant amount of time and is much slower than reading directly from RAM. If the system has to write a page to disk before it can read another page from disk, the performance impact is even worse.

Details of the Virtual Memory System

The logical address space of a process consists of mapped regions of memory. Each mapped memory region contains a known number of virtual memory pages. Each region has specific attributes controlling such things as inheritance (portions of the region may be mapped from “parent” regions), write-protection, and whether it is wired (that is, it cannot be paged out). Because regions contain a known number of pages, they are page-aligned, meaning the starting address of the region is also the starting address of a page and the ending address also defines the end of a page.

The kernel associates a VM object with each region of the logical address space. The kernel uses VM objects to track and manage the resident and nonresident pages of the associated regions. A region can map to part of the backing store or to a memory-mapped file in the file system. Each VM object contains a map that associates regions with either the default pager or the vnode pager. The default pager is a system manager that manages the nonresident virtual memory pages in the backing store and fetches those pages when requested. The vnode pager implements memory-mapped file access. The vnode pager uses the paging mechanism to provide a window directly into a file. This mechanism lets you read and write portions of the file as if they were located in memory.

In addition to mapping regions to either the default or vnode pager, a VM object may also map regions to another VM object. The kernel uses this self referencing technique to implement copy-on-write regions. Copy-on-write regions allow different processes (or multiple blocks of code within a process) to share a page as long as none of them write to that page. When a process attempts to write to the page, a copy of the page is created in the logical address space of the process doing the writing. From that point forward, the writing process maintains its own separate copy of the page, which it can write to at any time. Copy-on-write regions let the system share large quantities of data efficiently in memory while still letting processes manipulate those pages directly (and safely) if needed. These types of regions are most commonly used for the data pages loaded from system frameworks.

Each VM object contains several fields, as shown in Table 1.

If the VM object is involved in a copy-on-write (vm_copy) operation, the shadow and copy fields may point to other VM objects. Otherwise both fields are usually NULL.

Wired Memory

Wired memory (also called resident memory) stores kernel code and data structures that must never be paged out to disk. Applications, frameworks, and other user-level software cannot allocate wired memory. However, they can affect how much wired memory exists at any time. For example, an application that creates threads and ports implicitly allocates wired memory for the required kernel resources that are associated with them.

Table 2 lists some of the wired-memory costs for application-generated entities.

Note: These measurements may change with each new release of the operating system. They are provided here to give you a rough estimate of the relative cost of system resource usage.

As you can see, every thread, process, and library contributes to the resident footprint of the system. In addition to your application using wired memory, however, the kernel itself requires wired memory for the following entities:

Mac Os X Memory Management App Download

• VM objects

• the virtual memory buffer cache

• I/O buffer caches

• drivers

Wired data structures are also associated with the physical page and map tables used to store virtual-memory mapping information, Both of these entities scale with the amount of available physical memory. Consequently, when you add memory to a system, the amount of wired memory increases even if nothing else changes. When a computer is first booted into the Finder, with no other applications running, wired memory can consume approximately 14 megabytes of a 64 megabyte system and 17 megabytes of a 128 megabyte system.

Wired memory pages are not immediately moved back to the free list when they become invalid. Instead they are “garbage collected” when the free-page count falls below the threshold that triggers page out events.

Page Lists in the Kernel

The kernel maintains and queries three system-wide lists of physical memory pages:

• The active list contains pages that are currently mapped into memory and have been recently accessed.

• The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time.

• The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them.

When the number of pages on the free list falls below a threshold (determined by the size of physical memory), the pager attempts to balance the queues. It does this by pulling pages from the inactive list. If a page has been accessed recently, it is reactivated and placed on the end of the active list. In OS X, if an inactive page contains data that has not been written to the backing store recently, its contents must be paged out to disk before it can be placed on the free list. (In iOS, modified but inactive pages must remain in memory and be cleaned up by the application that owns them.) If an inactive page has not been modified and is not permanently resident (wired), it is stolen (any current virtual mappings to it are destroyed) and added to the free list. Once the free list size exceeds the target threshold, the pager rests.

The kernel moves pages from the active list to the inactive list if they are not accessed; it moves pages from the inactive list to the active list on a soft fault (see Paging In Process). When virtual pages are swapped out, the associated physical pages are placed in the free list. Also, when processes explicitly free memory, the kernel moves the affected pages to the free list.

Paging Out Process

In OS X, when the number of pages in the free list dips below a computed threshold, the kernel reclaims physical pages for the free list by swapping inactive pages out of memory. To do this, the kernel iterates all resident pages in the active and inactive lists, performing the following steps:

1. If a page in the active list is not recently touched, it is moved to the inactive list. Free screen grab software for mac.

2. If a page in the inactive list is not recently touched, the kernel finds the page’s VM object.

3. If the VM object has never been paged before, the kernel calls an initialization routine that creates and assigns a default pager object.

4. The VM object’s default pager attempts to write the page out to the backing store.

5. If the pager succeeds, the kernel frees the physical memory occupied by the page and moves the page from the inactive to the free list.

Note: In iOS, the kernel does not write pages out to a backing store. When the amount of free memory dips below the computed threshold, the kernel flushes pages that are inactive and unmodified and may also ask the running application to free up memory directly. For more information on responding to these notifications, see Responding to Low-Memory Warnings in iOS.

Paging In Process

The final phase of virtual memory management moves pages into physical memory, either from the backing store or from the file containing the page data. A memory access fault initiates the page-in process. A memory access fault occurs when code tries to access data at a virtual address that is not mapped to physical memory. There are two kinds of faults:

Mac Os X Download

• A soft fault occurs when the page of the referenced address is resident in physical memory but is currently not mapped into the address space of this process.

• A hard fault occurs when the page of the referenced address is not in physical memory but is swapped out to backing store (or is available from a mapped file). This is what is typically known as a page fault.

When any type of fault occurs, the kernel locates the map entry and VM object for the accessed region. The kernel then goes through the VM object’s list of resident pages. If the desired page is in the list of resident pages, the kernel generates a soft fault. If the page is not in the list of resident pages, it generates a hard fault.

For soft faults, the kernel maps the physical memory containing the pages to the virtual address space of the process. The kernel then marks the specific page as active. If the fault involved a write operation, the page is also marked as modified so that it will be written to backing store if it needs to be freed later.

For hard faults, the VM object’s pager finds the page in the backing store or from the file on disk, depending on the type of pager. After making the appropriate adjustments to the map information, the pager moves the page into physical memory and places the page on the active list. As with a soft fault, if the fault involved a write operation, the page is marked as modified.

Mac App Memory

Mac Os Memory

Copyright © 2003, 2013 Apple Inc. All Rights Reserved. Terms of Use Privacy Policy Updated: 2013-04-23