Whenever I'm viewing memory addresses within my Cocoa application, I notice (in general) 3 main categories of addresses
0x00006xxxxxxx
0x00007fffxxxx
0x0000001xxxxx
I have an idea of what is what-- like I noticed that the 0x00006xxxxxxx
addresses seem to be pointers to my application's objects?
and 0x0000001xxxxx
appears to be addresses to the actual objects in memory?
But I really am not sure of anything, and am unable to form good a Google query to give me an answer.
Does anybody have a resource, or know how to identify the categories of addresses in a Cocoa application?
Does anybody have a resource, or know how to identify the categories of addresses in a Cocoa application?
Addresses themselves don't fall into categories -- an address is an address. But it's true that there are different regions of memory that are used for different things, notably the stack and the heap. On many systems, MacOS included, the heap starts at a relatively low address and grows upward (addresses increase) while the stack starts at a high address and grows downward.
Objective-C objects are always allocated on the heap and accessed via pointers, so it makes sense that the addresses of objects themselves have low addresses whereas your pointers to objects (which are often global or local variables stored on the stack) have high addresses. Global variables exist at the base of the stack, so those will have higher addresses (again, the stack grows downward) than local variables.
The preceding paragraph notwithstanding, don't assume that an address indicates the type of thing stored at that location. While it's generally true that you won't find an Objective-C object on the stack, you will certainly find plenty of object pointers at addresses in the heap because objects contain pointers to other objects. As well, you may find blocks of other types of data: primitive data types (int
, char
, etc.), C-style arrays, data buffers, blocks, etc.
There are probably some other regions that I'm leaving out, such as space for code segments, but that's the general idea. It's often helpful to have an understanding of how memory is organized, but at the same time you should avoid writing code that relies on that knowledge unless you're writing software that requires it (e.g. a debugger).
If you want to know more, you could start with a couple of blog posts by Mike Ash:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With