Mac OS X is a slick, powerful operating system, but there's a cost to all that gloss. Most users don't ever bother to check, but many of the apps they use every day are notorious RAM-gobblers. Modern (Cocoa) applications on the Mac will be using ARC. (Automatic Reference Counting) to allocate and release RAM as needed. (There was a brief dalliance with garbage collection on the Mac a few years ago, but it ended badly. ) Many Windows. Historically, the classic Mac OS used a form of memory management that has fallen out of favor 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 engineers of the Macintosh was how to make optimum use of the 128 KB of RAM with which the machine was equipped, on Motorola 68000-based computer hardware that.
- Maco Memory Beta
- Maco Memory Alpha
- Macos App Memory Vs Wired Memory Foam
- Macos App Memory Vs Wired Memory Care
- Macos App Memory Vs Wired Memory Card
System cleanup in one click
It is infuriating to get the following message when using a Mac: Your system has run out of application memory.
Usually, this isn't the first sign that something is wrong. You may have noticed that your Mac isn't running as fast as it used to. Or it has been overheating recently, with the fan louder than normal as if it's struggling to carry a heavy load up a hill.
Running out of application memory doesn't always mean that your hard drive is full. What it means is your CPU can't manage to process and run all of the applications that are currently demanding processing memory power. Although Macs are wonderful computers, they're not supercomputers - they do have limits, and that message means yours has hit a processing limit. Thankfully, there is plenty you can do to resolve this problem and get your Mac operating smoothly again.
Reduce memory usage with Setapp
Instead of manually deleting files, get Setapp. It not only removes the clutter but also gives you full control over memory usage.
How do you check memory usage (CPU)?
If your Mac regularly runs into problems or you frequently experience the dreaded spinning color wheel, one of the potential causes could be your Mac's RAM running at close to its maximum capacity.
While memory management in macOS, including techniques like using your startup disk as virtual memory, is excellent these days, there are also more demands being placed on RAM thanks to new features and improvements. The more your Mac has to resort to virtual memory, the less well it will perform. And while the best solution is, if you can, to add more RAM, there are plenty of things you can do to reduce memory usage on your Mac.
Before you can identify which apps are causing problems, you need to know what is taking up so much CPU memory. There are a few ways you can do this.
First thing, find out what apps and processes are using the most memory.
Built into your Mac is an Activity Monitor.
Go to Applications > Activity Monitor. In here, it will show you everything using processing power at the moment. Apps absorbing CPU memory are usually shown as a percentage. Now that you can see what is causing the problem, consider closing uninstalling the ones you don't need.
Another way to solve this is with iStat Menus, a handy monitoring app that will quickly identify what is absorbing so much CPU power.
- When you see the Dashboard, switch on the components you want to see in your Mac's menu bar. While there, you should switch on the Memory tab.
- Click on the Memory icon in your menu bar and you'll see information about current memory usage on your Mac. Pressure shows the percentage of available RAM that's currently in use. And below that, you'll see a list of processes, starting with the one that's using the most RAM.
Tip: By default, iStat Menus shows only five processes, but you can make it show more. On the Dashboard, click the Memory tab and click on the Processes to show menu and select the number of processes you want to see.
Hover over the colored bar chart in each section to see a larger graph of memory usage. You can click on the tabs at the top of the graph to change the time period over which it shows memory usage.
iStat Menus also shows and keeps an automated eye on GPU, network data and disk usage.
Another app, also from Setapp - CleanMyMac - has an automated CPU and hard drive monitor built-in, which can give you a real-time view of memory usage - including your Dropbox account - in your Macs top toolbar.
By now, you'll have a good idea of how your Mac's memory has been used and whether it's caused your Mac to have problems. For a more detailed view on the processes that are hogging RAM, you can go to the bottom of the iStat Menus and click on the Activity Monitor icon (bottom panel, left most icon).
How to reduce your Mac memory usage
CPU memory can be used several ways. This usually isn't a problem to have apps running in the background, but once you've got too much going on your Mac can struggle to function; it can overheat, slow down, even crash and potentially lose what you've been working on.
A wide variety of applications can use processing memory. From startup items to browsers and plugins, to native and downloaded applications, to desktop widgets and apps. In this article, we will cover the various ways you can improve your Macs application memory.
#1: Fix 'kernel_task', a high CPU usage bug
Something you may have noticed through Activity Monitor or one of the apps mentioned in this article, is something called kernel_task is absorbing a large amount of processing power. One of the functions of kernel_task is to help manage CPU temperature; therefore you could find that your Macs fan is loud and always on, even if the device isn't hot to the touch.
kernel_task usually performs this way when one or more applications are trying to use to much CPU. It is working very hard to stop them. Unfortunately, one of the potential downsides - if this is a hardware fault - is a Mac can overheat to such an extent that internal systems are damaged, sometimes irreparably without qualified Apple tech support assistance.
Working through the following steps in this article is one way to avoid similar problems. If none of this work and kernel_task is still absorbing a high percentage of your CPU, then one or more of the following could be the cause:
- Cooling system inefficiency
- A failed or disconnected temperature sensor
- Another hardware issue, including a worn out batter.
- Your System Management Controller needs a rest.
If you've tried an SMC reset, deleted any app that could be contributed to the problem, and followed the steps in this article and nothing has worked, then it is worth taking your Mac to an Apple Store or qualified support technician.
#2: Reduce memory usage in Finder
One common culprit for hogging RAM is Finder, your Mac's file manager. If iStat Menus or Activity Monitor has highlighted Finder as using hundreds of MBs of RAM, there is an easy solution — change the default display for a new Finder window so it doesn't show All My Files.
- Click on the Finder icon in the Dock and click on the Finder menu, then select Preferences.
- Click on General. Under 'New Finder windows show', click the dropdown menu and choose any option except All My Files.
- Close Preferences, press Alt-Control, and click on the Finder icon in the Dock. Click Relaunch. Finder will now relaunch with new windows opening at the option you selected in Step 2.
While we're talking about Finder, your desktop behaves in a similar way.
Icons on your desktop are drawn and redrawn each time it changes, and their preview images are stored in RAM, so you can use Quick Look. The more files you have on your desktop, the more pressure they put on your Mac's memory. The simplest solution is to move files off the desktop. Declutter (available in Setapp) can help here. It moves files from your desktop to color-coded folders automatically, based on rules you set.
It is also worth applying the Merge All Windows setting, to avoid each window in Finder taking up more RAM. Avid venue standalone software mac.
#3: Improve Chrome's Task Manager
Chrome is a popular browser, especially if you use other Google products, such as Gmail and G Suite. But it can be bad news for your GPU, which negatively impacts how much memory it uses. Chrome uses a GPU Process as standard, which means it speeds up the loading of web pages, which can be great except at times when your computer is struggling with insufficient RAM.
To make this change, go to:
- Chrome Settings > More tools > Task Manager
- In Task Manager, click > Edit
- Within this, you can reduce memory usage on your Mac.
#4: Clean up browsers
In every browser you use regularly, there are always going to be extensions and popups that take up space and use RAM. Either go through each one manually, or use a tool such as CleanMyMac to identify and delete them.
Get CMM X to free up space
Install CleanMyMac X and streamline the entire process of memory management on Mac. Clever memory usage control done for you.
With Chrome it can take a little more work to delete extensions. While Chrome extensions are shown in CleanMyMac, you have to remove them from Chrome. If you identify a Chrome extension that uses too much RAM, launch Chrome, click on the Window menu, then Extensions. Scan the list of extensions and click the trash can icon next to those that are too RAM-heavy or no longer needed.
It is also worth limiting the number of tabs you have open to keep browser CPU usage to a minimum.
#5: Disable login items
Login items, browser extensions, and preference panes, such as Flash, are another common source of memory usage. Most of us have several installed that we rarely use, but which hog memory and reduce performance.
One way to do this is through System Preferences:
- Users & Groups >Login Items tab
- Then delete everything that is clearly taking up memory that could be put to better use.
Another way, one that is even quicker, is to employ CleanMyMac to identify and cleanup login items.
- Launch CleanMyMac and look for the Speed section in the left-hand sidebar and click on Optimization.
- In the next panel, click on Login items. If there are any login items you don't need or which showed up in iStat Menus as using lots of RAM, click on the checkbox next to their name and then Remove.
Not all login items can be removed on their own. Those that can't have an 'i' in place of the checkbox. Click on it to find out why it can't be removed. One common reason is being required by the application that installed it — the only way to remove it would be to uninstall the application.
If you don't use the application, click on the Uninstaller tool in CleanMyMac. Check the box next to the name of the app and click Uninstall. The app, its associated files, and the login item will be removed.
#6: Disable desktop widgets
Desktop widgets can provide a useful shortcut to apps you need to access fairly often. But they can take up processing memory that is slowing your whole Mac down. One way to close them completely is in System Preferences.
Go to: Mission Control > switch off the Dashboard
#7: Declutter your desktop
Your desktop is meant to be a way to find important files and documents you are currently working on. And apps you need often. And anything else that you maybe happen to need one day. Pretty soon, a desktop can look like a suitcase you've packed for every possible eventuality. A complete mess! And impossible to find what you really need.
Plus, a messy desktop can absorb valuable processing power. Either spend time manually sorting files into folders, and vowing to keep it tidy. Or use an app - such as Declutter or Spotless - to quickly arrange folders and declutter your desktop.
#8: Reduce startup items at least 20%
Most startup disk drives contain a whole load of things people don't need anymore. Either an old-fashioned and manual decluttering should remove at least 20% of these files and apps, or you can use a tool such as CleanMyMac to remove junk. Another problem is Adobe Flash - an application that is largely useless online due to security flaws and weaknesses.
Adobe Flash is a major culprit when it comes to hogging RAM and making your Mac run slowly. Most videos on the web today don't need Flash.
How to remove Flash?
To get Flash off of your Mac in common way, you'll need an uninstaller from Adobe and follow a huge Adobe instruction. Instead downloading anything extra to uninstall Flash, you can use CleanMyMac via Setapp.
#9: Schedule regular cleanups
Consider that every time you use your Mac it slows down a little bit. You use more files, install more apps, and take up more storage. While going through the cleaning process described above isn't an everyday routine, try to schedule it monthly and stick to it. Your Mac will thank you for it.
It is also worth fully shutting down your Mac more often. It will perform better. Speed up and stop overheating as much when it is allowed to shut down instead of going to sleep.
CPU use can have a serious impact on the health of your Mac. Not only can it slowdown and start to overheat, but if problems persist it can cause a critical failure. Keep your Mac free of clutter and healthy. Remove folders and apps you don't need, and keep an eye on startup items, browser extensions, your desktop, widgets, and anything else that is shown as a CPU hog in Activity Monitor. Your Mac will perform at its best for far longer with regular care and cleanups.
Maco Memory Beta
Historically, the classic Mac OS used a form of memory management that has fallen out of favor 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 engineers of the Macintosh was how to make optimum use of the 128 KB of RAM with which the machine was equipped, on Motorola 68000-based computer hardware that did not support virtual memory.[1] Since at that time the machine could only run one application program at a time, and there was no fixedsecondary storage, the engineers implemented a simple scheme which worked well with those particular constraints. That design choice did not scale well with the development of the machine, creating various difficulties for both programmers and users.
Fragmentation[edit]
The primary concern of the original engineers appears to have been fragmentation - that is, the repeated allocation and deallocation of memory through pointers leading to many small isolated areas of memory which cannot be used because they are too small, even though the total free memory may be sufficient to satisfy a particular request for memory. To solve this, Apple engineers used the concept of a relocatable handle, a reference to memory which allowed the actual data referred to be moved without invalidating the handle. Apple's scheme was simple - a handle was simply a pointer into a (non relocatable) table of further pointers, which in turn pointed to the data.[2]If a memory request required compaction of memory, this was done and the table, called the master pointer block, was updated. The machine itself implemented two areas in memory available for this scheme - the system heap (used for the OS), and the application heap.[3]As long as only one application at a time was run, the system worked well. Since the entire application heap was dissolved when the application quit, fragmentation was minimized.
The memory management system had weaknesses; the system heap was not protected from errant applications, as would have been possible if the system architecture had supported memory protection, and this was frequently the cause of system problems and crashes.[4]In addition, the handle-based approach also opened up a source of programming errors, where pointers to data within such relocatable blocks could not be guaranteed to remain valid across calls that might cause memory to move. This was a real problem for almost every system API that existed. Because of the transparency of system-owned data structures at the time, the APIs could do little to solve this. Thus the onus was on the programmer not to create such pointers, or at least manage them very carefully by dereferencing all handles after every such API call. Since many programmers were not generally familiar with this approach, early Mac programs suffered frequently from faults arising from this.[5]
Palm OS and 16-bit Windows use a similar scheme for memory management, but the Palm and Windows versions make programmer error more difficult. For instance, in Mac OS, to convert a handle to a pointer, a program just de-references the handle directly, but if the handle is not locked, the pointer can become invalid quickly. Calls to lock and unlock handles are not balanced; ten calls to HLock are undone by a single call to HUnlock.[6] In Palm OS and Windows, handles are an opaque type and must be de-referenced with MemHandleLock on Palm OS or Global/LocalLock on Windows. When a Palm or Windows application is finished with a handle, it calls MemHandleUnlock or Global/LocalUnlock. Palm OS and Windows keep a lock count for blocks; after three calls to MemHandleLock, a block will only become unlocked after three calls to MemHandleUnlock.
Addressing the problem of nested locks and unlocks can be straightforward (although tedious) by employing various methods, but these intrude upon the readability of the associated code block and require awareness and discipline on the part of the coder.
Memory leaks and stale references[edit]
Maco Memory Alpha
Awareness and discipline are also necessary to avoid memory 'leaks' (failure to deallocate within the scope of the allocation) and to avoid references to stale handles after release (which usually resulted in a hard crash—annoying on a single-tasking system, potentially disastrous if other programs are running).
Switcher[edit]
The situation worsened with the advent of Switcher, which was a way for a Mac with 512KB or more of memory to run multiple applications at once.[7] This was a necessary step forward for users, who found the one-app-at-a-time approach very limiting. Because Apple was now committed to its memory management model, as well as compatibility with existing applications, it was forced to adopt a scheme where each application was allocated its own heap from the available RAM.[8]The amount of actual RAM allocated to each heap was set by a value coded into the metadata of each application, set by the programmer. Sometimes this value wasn't enough for particular kinds of work, so the value setting had to be exposed to the user to allow them to tweak the heap size to suit their own requirements. While popular among 'power users', this exposure of a technical implementation detail was against the grain of the Mac user philosophy. Apart from exposing users to esoteric technicalities, it was inefficient, since an application would be made to grab all of its allotted RAM, even if it left most of it subsequently unused. Another application might be memory starved, but would be unable to utilize the free memory 'owned' by another application.[3]
While an application could not beneficially utilize a sister application's heap, it could certainly destroy it, typically by inadvertently writing to a nonsense address. An application accidentally treating a fragment of text or image, or an unassigned location as a pointer could easily overwrite the code or data of other applications or even the OS, leaving 'lurkers' even after the program was exited. Such problems could be extremely difficult to analyze and correct.
Switcher evolved into MultiFinder in System 4.2, which became the Process Manager in System 7, and by then the scheme was long entrenched. Apple made some attempts to work around the obvious limitations – temporary memory was one, where an application could 'borrow' free RAM that lay outside of its heap for short periods, but this was unpopular with programmers so it largely failed to solve the problems. Apple's System 7 Tune-up addon added a 'minimum' memory size and a 'preferred' size—if the preferred amount of memory was not available, the program could launch in the minimum space, possibly with reduced functionality. This was incorporated into the standard OS starting with System 7.1, but still didn't address the root problem.[9]
Virtual memory schemes, which made more memory available by paging unused portions of memory to disk, were made available by third-party utilities like Connectix Virtual, and then by Apple in System 7. This increased Macintosh memory capacity at a performance cost, but did not add protected memory or prevent the memory manager's heap compaction that would invalidate some pointers.
32-bit clean[edit]
Originally the Macintosh had 128 kB of RAM, with a limit of 512 kB. This was increased to 4 MB upon the introduction of the Macintosh Plus. These Macintosh computers used the 68000 CPU, a 32-bit processor, but only had 24 physical address lines. The 24 lines allowed the processor to address up to 16 MB of memory (224 bytes), which was seen as a sufficient amount at the time. The RAM limit in the Macintosh design was 4 MB of RAM and 4 MB of ROM, because of the structure of the memory map.[10] This was fixed by changing the memory map with the Macintosh II and the Macintosh Portable, allowing up to 8 MB of RAM.
Because memory was a scarce resource, the authors of the Mac OS decided to take advantage of the unused byte in each address. The original Memory Manager (up until the advent of System 7) placed flags in the high 8 bits of each 32-bit pointer and handle. Each address contained flags such as 'locked', 'purgeable', or 'resource', which were stored in the master pointer table. When used as an actual address, these flags were masked off and ignored by the CPU.[4]
While a good use of very limited RAM space, this design caused problems when Apple introduced the Macintosh II, which used the 32-bit Motorola 68020 CPU. The 68020 had 32 physical address lines which could address up to 4 GB (232 bytes) of memory. The flags that the Memory Manager stored in the high byte of each pointer and handle were significant now, and could lead to addressing errors.
In theory, the architects of the Macintosh system software were free to change the 'flags in the high byte' scheme to avoid this problem, and they did. For example, on the Macintosh IIci and later machines, HLock() and other APIs was rewritten to implement handle locking in a way other than flagging the high bits of handles. But, many Macintosh application programmers and a great deal of the Macintosh system software code itself accessed the flags directly rather than using the APIs, such as HLock(), which had been provided to manipulate them. By doing this they rendered their applications incompatible with true 32-bit addressing, and this became known as not being '32-bit clean'.
In order to stop continual system crashes caused by this issue, System 6 and earlier running on a 68020 or a 68030 would force the machine into 24-bit mode, and would only recognize and address the first 8 megabytes of RAM, an obvious flaw in machines whose hardware was wired to accept up to 128 MB RAM – and whose product literature advertised this capability. With System 7, the Mac system software was finally made 32-bit clean, but there were still the problem of dirty ROMs. The problem was that the decision to use 24-bit or 32-bit addressing has to be made very early in the boot process, when the ROM routines initialized the Memory Manager to set up a basic Mac environment where NuBus ROMs and disk drivers are loaded and executed. Older ROMs did not have any 32-bit Memory Manager support and so was not possible to boot into 32-bit mode. Surprisingly, the first solution to this flaw was published by software utility company Connectix, whose 1991 product MODE32 reinitialized the Memory Manager and repeated early parts of the Mac boot process, allowing the system to boot into 32-bit mode and enabling the use of all the RAM in the machine. Apple licensed the software from Connectix later in 1991 and distributed it for free. The Macintosh IIci and later Motorola based Macintosh computers had 32-bit clean ROMs.
Macos App Memory Vs Wired Memory Foam
It was quite a while before applications were updated to remove all 24-bit dependencies, and System 7 provided a way to switch back to 24-bit mode if application incompatibilities were found.[3] By the time of migration to the PowerPC and System 7.1.2, 32-bit cleanliness was mandatory for creating native applications and even later Motorola 68040 based Macs could not support 24-bit mode.[6][11]
Object orientation[edit]
The rise of object-oriented languages for programming the Mac – first Object Pascal, then later C++ – also caused problems for the memory model adopted. At first, it would seem natural that objects would be implemented via handles, to gain the advantage of being relocatable. These languages, as they were originally designed, used pointers for objects, which would lead to fragmentation issues. A solution, implemented by the THINK (later Symantec) compilers, was to use Handles internally for objects, but use a pointer syntax to access them. This seemed a good idea at first, but soon deep problems emerged, since programmers could not tell whether they were dealing with a relocatable or fixed block, and so had no way to know whether to take on the task of locking objects or not. Needless to say this led to huge numbers of bugs and problems with these early object implementations. Later compilers did not attempt to do this, but used real pointers, often implementing their own memory allocation schemes to work around the Mac OS memory model.
While the Mac OS memory model, with all its inherent problems, remained this way right through to Mac OS 9, due to severe application compatibility constraints, the increasing availability of cheap RAM meant that by and large most users could upgrade their way out of a corner. The memory wasn't used efficiently, but it was abundant enough that the issue never became critical. This is ironic given that the purpose of the original design was to maximise the use of very limited amounts of memory. Mac OS X finally did away with the whole scheme, implementing a modern sparse virtual memory scheme. A subset of the older memory model APIs still exist for compatibility as part of Carbon, but map to the modern memory manager (a threadsafe malloc implementation) underneath.[6]Apple recommends that Mac OS X code use malloc and free 'almost exclusively'.[12]
References[edit]
- ^Hertzfeld, Andy (September 1983), The Original Macintosh: We're Not Hackers!, retrieved 2010-05-10
- ^Hertzfeld, Andy (January 1982), The Original Macintosh: Hungarian, retrieved 2010-05-10
- ^ abcmemorymanagement.org (2000-12-15), Memory management in Mac OS, archived from the original on 2010-05-16, retrieved 2010-05-10
- ^ abHertzfeld, Andy, The Original Macintosh: Mea Culpa, retrieved 2010-05-10
- ^Apple Computer (1985-10-01), Technical Note OV09: Debugging With PurgeMem and CompactMem, retrieved 2010-05-10
- ^ abcLegacy Memory Manager Reference, Apple Inc, 2007-06-27, retrieved 2010-05-10
- ^Hertzfeld, Andy (October 1984), The Original Macintosh: Switcher, retrieved 2010-05-10
- ^Mindfire Solutions (2002-03-06), Memory Management in Mac OS(PDF), p. 2, retrieved 2010-05-10
- ^'System 7.1 upgrade guide'(PDF).
- ^'memory maps'. Osdata.com. 2001-03-28. Retrieved 2010-05-11.
- ^Apple Computer (1991-01-01), Technical Note ME13: Memory Manager Compatibility, retrieved 2010-05-10
- ^Memory Allocation Recommendations on OS X, Apple Inc, 2005-07-12, retrieved 2009-09-22
External links[edit]
Macos App Memory Vs Wired Memory Care
- Macintosh: ROM Size for Various Models, Apple Inc, 2000-08-23, retrieved 2009-09-22