Showing entries tagged "memory". Full blog index
classes tend to be straightforward for most people new to the language to understand. They work pretty much like classes in any other language. Whether you've come from Objective-C or Java or Ruby, you've worked with something similar. Swift's
structs are another matter. They look sort of like
classes, but they're value types, and they don't do inheritance, and there's this copy-on-write thing I keep hearing about? Where do they live, anyway, and how do they work? Today, I'm going to take a close look at just how
structs get stored and manipulated in memory.
Zombies are a valuable tool for debugging memory management problems. I previously discussed the implementation of zombies
, and today I'm going to go one step further and build them from scratch, a topic suggested by Шпирко Алексей.
vulnerability made a big splash a couple of months ago, and rightly so. It could be described as a "memory leak", but it's not the standard kind where a program fails to free allocated memory. Instead, it allowed an attacker to dump memory contents from a remote program nearly at will, potentially leaking private keys, passwords, source code, and other data intended to stay secret. This got me thinking about ways to protect sensitive data against similar attacks. The result is MAParanoidAllocator
, and in this article I'll discuss the implementation.
Welcome back to another Friday Q&A. I apologize for the unannounced hiatus in posts. It's not due to anything interesting, just a shortage of time. Friday Q&A will continue, and I will continue to aim for my regular biweekly postings. For today's article, I have a little story about an
autorelease call that didn't do what it was supposed to do.
In the previous article on ARM64
, I mentioned that one advantage of the new architecture is the fact that it has twice as many registers, allowing code load data from RAM less often, which is much slower. Reader Daniel Hooper asks the natural question: just why is
RAM so much slower than registers?
The hardware and software that our apps run on is almost frighteningly complicated, and there's no better place to see that than in the contortions that the system goes through when we load data from memory. What exactly happens when we load a byte of memory? Reader and friend of the blog Guy English suggested I dedicate an article to answering that question.
I'm back from my hiatus and ready with a fresh journey into the netherworld of Apple's platforms. Today's subject comes from several readers who suggested that I discuss the subtleties of dealing with memory management and nibs, and particularly the differences between the Mac and iOS.
Last time on Friday Q&A
, I started talking about implementing a ring buffer using virtual memory tricks to mirror memory. The first article concentrated on those virtual memory tricks. Today, I'm going to fill out the second half of the puzzle and show how to implement the ring buffer on top of the mirrored memory allocator we developed. If you haven't read the previous article
yet, I strongly recommend you so so, otherwise the memory mirroring is likely to be confusing.
Playing with virtual memory is always fun, and one place where it can be put to good use is in building a ring buffer. A ring buffer is a way to implement a FIFO queue of data, and using virtual memory tricks to mirror multiple copies of the same data can make the implementation simpler and better by virtually concatenating noncontiguous data. Readers Jose Vazquez and Dylan Lukes suggested that I explore the building of such a construct. Today I will talk about how to implement the virtual memory tricks, and then in part II I will show how to implement the ring buffer on top of them.
I gave two presentations at the Voices That Matter conference in Boston in November. Both presentations were recorded and the videos are now available for purchase. And as a special present for my readers, you can get 35% off!
Since the moment Apple announced it, readers have asked me to write about Automatic Reference Counting, or ARC. Today is the day. I'll talk about Apple's new memory management system, how it works, and how to get the most out of it.
Last time, I discussed how to build
NSAutoreleasePool and how it works internally. Today, I'm going to carry that theme forward by building an implementation of Cocoa reference counting with
release, a topic suggested by David Dunham.
It's Friday again, that Fridayest of days, and this week that means it's time for another Friday Q&A. Samuel Goodwin suggested discussing how
NSZombie works, and that's the topic I will discuss today.
Merry holidays, happy winter, and a joyous Friday Q&A to you all. Camille Troillard suggested that I discuss how to create custom object memory allocators in Objective-C, and today I'm going to walk through how to accomplish this and why you might want to.
It's once again time for a brand new edition of Friday Q&A. This week, I'm going to talk about accessors, and how to properly deal with memory management and thread safety when creating them, a topic suggested by Daniel Jalkut
Happy iPad 3G day to everyone. Whether you're waiting in line, waiting for the delivery guy, or just pining at home like I am, you can fill your idle moments with another edition of Friday Q&A. This week, Filip van der Meeren has suggested that I discuss retain cycles and how to deal with them.
Welcome to another Friday Q&A. I survived my travel and am (just barely) ready to write another exciting edition. This week's topic comes from Gwynne
, who asked why Objective-C only uses heap objects, and no stack objects.
Welcome back to another Friday Q&A. Now that WWDC is behind us, I'm back on track to bring you more juicy highly-technical goodness. Maybe I can even get back to doing one a week.... This week I'm going to take André Pang's suggestion of discussing process memory statistics (the stuff you see in Activity Monitor or
top) in Mac OS X.