Free and increase Mac system memory with CleanGenius Free Memory and speed up Mac OS. Show Mac's memory available and optimize system memory for Mac OS X 10.7 or later just by a click. Free download to keep your Mac clean and healthy now. If your Mac has slowed down it's possible that your RAM is being used to the max. Here's how to free up memory on a Mac (or how to free up RAM), including ways to reduce Mac RAM usage without. Download the latest version of Memory Diag for Mac - Monitor, optimize, and diagnose memory usage. Read 5 user reviews of Memory Diag on MacUpdate. I have a question about the system memory of my mac and it seems like you might know the answer. I have used boot camp to set aside system memory space for windows. But later I decided not to install windows. I used the way you have advised and got to the activity monitor and here is what I got for the numbers: free: 1.34GB. Thus, it boosts performance and helps manage device memory issues. Apple also introduced new formats for video and photos in this version. These formats compress data - that’s a benefit as files can get huge with ever-rising resolutions.

“No matter what I do, my Mac is still slow”, an average tech-consultant hears this phrase multiple times a day. Give a person even the most powerful computer, and pretty soon it will be cluttered with apps, extensions, and things that are too much for it to handle. To reverse it, one has to go back and сlean up the mess, removing memory agents one by one. Prepare for a fight — every byte of memory is at stake. So let’s put your Mac on a diet and get it more free RAM to breathe freely.

First, remove desktop clutter. Get a combination of Setapp apps that clear away unneeded desktop files.

“Your system has run out of application memory”

How do you know your Mac is low on memory? Floating “rainbow wheels” aside, you may notice your Mac now takes ages to load. You’ll also see many browser applications crashing. You’ll be also thrown warning messages as “Your system has run out of application memory”. To help it, you should first visit the Activity monitor to see memory usage on Mac.

How to check RAM usage on Mac

Go to Applications and type in Activity Monitor in the search bar. This invokes a good old Activity Monitor that should tell how much free memory you’ve got left.

A shortcut to open Activity Monitor:

Press F4 and start typing Activity Monitor in the search bar.

I’ve attached a screenshot from my Mac and as you can see my memory usage almost reached full capacity. Here’s what it all means:

App memory: taken by apps and processes
Wired memory: reserved by apps, can’t be freed up
Compressed: inactive, can be used by other apps
Swap used: memory used by macOS
Cached files: memory you can really use

Notice the colored graph under Memory Pressure. If your graph is all but red and yellow, your Mac is really gasping for fresh memory. It seems counter-intuitive, but “available memory” your Activity Monitor is not that important after all. In fact, it’s a system intended behavior to use all memory resources when available. On the contrary, the Memory Pressure graph is much more telling, so grow a habit to check this graph in the Activity Monitor every now and then.

How to check CPU usage on Mac

Open the CPU tab in Activity Monitor to keep in check CPU-heavy processes. Normally an app would be using 0-4% of CPU. If it takes abnormally more than that, go inside that particular item in the list and press the Quit button.

How to free up memory on Mac

Tip # 1. Remove Login Items to lower Mac memory usage

Login items are programs that load automatically upon Mac startup. Some of them covertly add themselves to the list and this is no good. If you’re looking to free up RAM, they are the first candidates for deletion. Don’t worry, you’re not deleting the app itself, you just stop it from auto-launching every time.

So, to remove Login Items and at the same time reduce your memory usage of your Mac, you need to:

1. Open System Preferences and select Users & Groups.
2. Click your nickname on the left.
3. Select the Login Items tab.
4. Check programs you don’t want to load as your Mac starts.
5. Press the “–” sign below.

Now, you won’t see these apps pop up the moment you turn on your Mac. Although this method doesn’t require some superpowers of yours, some special Mac optimization and memory cleaner tools may do the job faster and ensure the smooth performance of your Mac. CleanMyMac X is an excellent example of such software. Here’s how to disable Login Items with CleanMyMac X:

1. Download it for free and go to the Optimization tab.
2. Check Login Items to see the list of apps that get opened when you start your Mac.
3. Click Remove.

As you’ve already come to the Optimization module of CleanMyMac, you can also fix hung apps and heavy memory consumers there. In this way, you’ll free up the solid amount of RAM on Mac — 100% free of charge.

Tip # 2. Free up disk space if Mac is low on memory

The available space on your Mac’s drive translates into virtual memory. This comes to save you when you’ve run out of physical RAM. So now your computer relies on your hard drive space to keep your apps going.

The classic geek rule of thumb holds it that you should keep at least 20% of disk space on your startup drive. Not only this potentially reduces your future spending on iCloud storage but it also keeps your Mac speedier.

What to delete to free up space:

• Large unused files, like movies
• Old downloads
• Rarely used applications
• System junk

But here’s a simpler solution to save your time — clean up your drive with CleanMyMac X— the app I’ve mentioned above. Many users recommend it as an excellent way to free up more space because it searches for large & old files, useless system files, Photo junk, mail attachments and shows everything you can safely delete. Interestingly, it finds about 74 GB of junk on an average computer.

Extra trick: How to free up RAM on Mac with CleanMyMac X

If you have downloaded CleanMyMac, you may also take advantage of its amazing feature — the ability to free up RAM in a few seconds. Try this next time you see “Your system has run out of application memory” message.

1. Go to the Maintenance tab on the left.
2. Click Free Up RAM.
3. Click Run.

Free Mac Os For Windows

As simple as that!

And you can do it even if you download a free version of the app.

Tip # 3. Clean up your Desktop

This tip always comes at the bottom of instructions and unfairly so as it is quite effective. Without even looking at your Desktop I would assume it’s cluttered with mountains of icons. Thing is, your macOS was designed in a way that it treats every Desktop icon as a little active window. The more icons, the heavier memory usage on Mac. So in order to release available memory resources, it’s recommended to keep your Desktop clean.

You don’t have to do it all by yourself. With apps like Declutter and Spotless, every desktop cleaning session will be scheduled in advance and executed automatically. Your only job is to define the rules on how your files should be organized.

Tip #4. Clear cache files

Another way to free up RAM on Mac is to clear it of cache files. Of course, it won’t save you gigabytes of space, but deleting cache regularly, you can help your Mac run faster and avoid system issues.

So, to remove cache files on your Mac, you need to:

1. Open Finder.
2. From the Go menu, select Go to Folder.
3. Type ~/Library/Caches in the field and press Go.
4. In the window that appears, you will see all your cache files.
5. Press Command+A to select all files or delete files one by one.
6. Enter your user name and password to confirm.

If you find some files still in the folder after you emptied it, maybe you have some windows open on your Mac. Just like that, you can save up some space on your Mac. Don’t forget to empty the bin afterward.

Tip # 5. Tune up Chrome’s Task Manager

Although Google Chrome is not the one to blame for massive memory usage, it can indeed affect your Mac's performance. If you use Chrome as your primary browser, you probably have many windows opened there. Chrome runs a lot of processes to ensure a fast browsing experience for you. So, it uses your RAM for storing your tabs, plugins, and extensions. Look at how many entries Google Chrome has in Activity Monitor:

The question then arises, 'Why does Chrome use so much RAM?' The thing is that each process is responsible for a separate plugin or extension of your browser. For example, when a tab unexpectedly falls, you need to refresh it to continue your work there. If one process were responsible for all tabs and extensions, you would need to restart the whole browser instead. Can you imagine how many times would you do that? That’s the proper answer to why Chrome uses so much RAM.

I’ve been using Chrome for some years only to discover (recently) that Chrome had a task manager of its own. You can use it to force quit memory-heavy processes in the browser. It’s a handy tool because it lets you see how a page weighs on CPU usage on a Mac.

1. Go to Chrome settings (dotted icon in the top right corner)
2. Click More tools -> Task Manager
   

To free up even more RAM, close the GPU process. The GPU Process, though helpful in theory to accelerate pages, eats up a considerable amount of memory. Click to end it to free up RAM on your Mac.

Tip # 6. Manage RAM usage with CleanMyMac X menu

CleanMyMac X has another useful and convenient feature for managing your Mac’s performance and memory usage. As you install CleanMyMac X and start it for the first time, it’s icon will appear in your menu bar. Click the icon to open the CleanMyMac X menu. Here you can find updates on the current condition of your Mac and perform quick tweaks to increase your Mac's speed. Whenever you feel like your Mac underperforms, open the CleanMyMac X menu to check how much RAM is available and free it up as well.

Tip # 7. Close Finder windows

Okay, suppose you’re still asking yourself, how do I clear RAM on my MacBook Pro/MacBook Air. The next trick is as magical (you’ll see for yourself) as it is time-saving. It’s no secret that each window in the Finder eats up RAM. But how many open windows are there? Some of them are collapsed or stacked in some blind spot on your screen. This Finder command merges all your windows into one. See how to do it:

Click on Finder > Window > Merge All Windows

Now you can manage Finder windows more effectively and free up memory on MacBook.

What else you can do to minimize memory usage on Mac

I’ve saved the easiest tips for the end, as long as these ones are self-explanatory.

• Replace AdBlock (very memory-demanding) with a lighter extension
• Keep fewer opened tabs in the browser
• Restart your Mac more often to free up RAM
• Close all hung-up print queues

That was my take on how to make your Mac a bit speedier to use. If you’re looking for more guidance, check simple ways to speed up your Mac.

Frequently Asked Questions

How to check application memory on Mac?

To check RAM usage on your Mac, go to Activity Monitor (Applications > Utilities). In the Memory tab, you will see all the active processes that are using your Mac’s RAM. At the end of the window, there is a Memory Used graph, which indicates how much application memory is used.

How to find out whether your Mac needs more RAM?

Your Mac may be using almost all its RAM, but you don’t need more if it’s using it efficiently. Open Activity Monitor and go to the Memory tab. The Memory Pressure graph shows the current condition of your RAM: green color means your Mac’s using RAM effectively, while yellow is a sign that some application or process is using too much of application memory. The red memory pressure signals that your Mac needs more RAM.

How to quickly free up RAM on your MacBook?

To free up RAM on your Mac, firstly, you should find out what app uses so much of your memory. The memory-heavy programs are listed in Activity Monitor, Memory tab. If there is an app you aren’t using at the moment, click it and press the “X” sign to quit it. This will, in turn, free some of the application memory

These might also interest you:

Free Memory For Mac Os Versions

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]

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 (2²⁴ 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 (2³² 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.

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]

1. ^Hertzfeld, Andy (September 1983), The Original Macintosh: We're Not Hackers!, retrieved 2010-05-10
2. ^Hertzfeld, Andy (January 1982), The Original Macintosh: Hungarian, archived from the original on 2010-06-19, retrieved 2010-05-10
3. ^ ^abcmemorymanagement.org (2000-12-15), Memory management in Mac OS, archived from the original on 2010-05-16, retrieved 2010-05-10
4. ^ ^abHertzfeld, Andy, The Original Macintosh: Mea Culpa, retrieved 2010-05-10
5. ^Apple Computer (1985-10-01), Technical Note OV09: Debugging With PurgeMem and CompactMem, retrieved 2010-05-10
6. ^ ^abcLegacy Memory Manager Reference, Apple Inc, 2007-06-27, retrieved 2010-05-10
7. ^Hertzfeld, Andy (October 1984), The Original Macintosh: Switcher, retrieved 2010-05-10
8. ^Mindfire Solutions (2002-03-06), Memory Management in Mac OS(PDF), p. 2, retrieved 2010-05-10
9. ^'System 7.1 upgrade guide'(PDF). Archived from the original(PDF) on 2016-03-04. Retrieved 2015-05-26.
10. ^'memory maps'. Osdata.com. 2001-03-28. Retrieved 2010-05-11.
11. ^Apple Computer (1991-01-01), Technical Note ME13: Memory Manager Compatibility, retrieved 2010-05-10
12. ^Memory Allocation Recommendations on OS X, Apple Inc, 2005-07-12, retrieved 2009-09-22

External links[edit]

• Macintosh: ROM Size for Various Models, Apple Inc, 2000-08-23, retrieved 2009-09-22