Objective-C 中的栈对象与堆对象

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2010-01-15-stack-and-heap-objects-in-objective-c.html

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.

Before we get into that, let’s define our terms.

Stack The stack is a region of memory which contains storage for local variables, as well as internal temporary values and housekeeping. On a modern system, there is one stack per thread of execution. When a function is called, a stack frame is pushed onto the stack, and function-local data is stored there. When the function returns, its stack frame is destroyed. All of this happens automatically, without the programmer taking any explicit action other than calling a function.

Heap The heap is, essentially, everything else in memory. (Yes, there are things other than the stack and heap, but let’s ignore that for this discussion.) Memory can be allocated on the heap at any time, and destroyed at any time. You have to explicitly request for memory to be allocated from the heap, and if you aren’t using garbage collection, explicitly free it as well. This is where you store things that need to outlive the current function call. The heap is what you access when you call malloc and free.

Stack vs Heap Objects Given that, what’s a stack object, and what’s a heap object?

First, we must understand what an object is in general. In Objective-C (and many other languages), an object is simply a contiguous blob of memory with a particular layout. (If you’re interested in just what it contains and how it’s laid out, check out my intro to the Objective-C runtime.)

The precise location of that memory is less important. As long as you have some memory somewhere with the right contents, it’s a working Objective-C object. In Objective-C, objects are usually created on the heap:

1
    NSObject *obj = [[NSObject alloc] init];

A stack object is just an object where the memory for that object is allocated on the stack. Objective-C doesn’t have any support for this directly, but you can construct one manually without too much trouble:

1
    struct {
2
        Class isa;
3
    } fakeNSObject;
4
    fakeNSObject.isa = [NSObject class];
5

6
    NSObject *obj = (NSObject *)&fakeNSObject;
7
    NSLog(@"%@", [obj description]);

Advantages of Stack Objects It’s obviously possible to have stack objects in general. Aside from the above hack, real languages like C++ have language support for stack objects. In C++, you can create objects on the stack or the heap:

1
    std::string stackString;
2
    std::string *heapString = new std::string;

Stack objects have two compelling advantages:

• Speed: Allocating memory on the stack is really fast. All of the bookkeeping is done by the compiler when you build your program. At runtime, the function prolog just carves out the amount of space it needs for all local variables, and the code knows what goes where because it was all computed in advance. Stack allocations are essentially free, whereas heap allocations can be quite expensive.

• Simplicity: Stack objects have a defined lifetime. You can never leak one, because it always gets destroyed at the end of the scope where it was declared.

(Note: it’s not an impossibility in general, and many languages move objects around as a matter of course, often as part of garbage collection schemes. However, this requires more runtime smarts and a stricter type system than you get in Objective-C.)

As used in Cocoa, Objective-C uses a reference counting system for memory management. The advantage of this system is that any single object can have multiple “owners”, and the system won’t allow the object to be destroyed until all owners have relinquished ownership.

Stack allocated objects inherently have a single owner, the function which created them. If Objective-C had stack objects, what would happen if you passed it to some other code which then tried to keep it around by retaining it? There’s no way to prevent the object from being destroyed when the function which created it returns, so the retain can’t work. The code which tries to keep the object around will fail, end up with a dangling reference, and will crash.

Another problem is that stack objects are not very flexible. It’s not uncommon in Objective-C to implement an initializer which destroys the original object and returns a new one instead. How could you do that with a stack object? You really couldn’t. Much of the runtime flexibility of Objective-C depends on having heap objects.

Actual Stack Objects in Objective-C It turns out that Objective-C does have stack objects, truly and officially, as of 10.6!

Don’t get too excited, though. It’s only supported for a single kind of object: blocks. When you write a block inside a function using the ^{} syntax, the result of that expression is a stack object!

But what about those problems I discussed above?

The problem with runtime dynamism doesn’t exist with blocks. Blocks have a layout which is fixed by the language, and which can’t be changed without destroying binary compatibility. The size of the block object can be computed at compile time, and in fact the whole object is built by compiler-generated code, so the possibility of writing an initializer that does tricky things simply doesn’t exist.

The problem of object lifetime does exist with blocks, but is less severe. The reason for this is simply because blocks are a new kind of object that never existed in the language before, and any code that deals with a block will know that it needs to copy a block (which creates a copy on the heap, if it’s not there already, and returns a pointer to that), rather than retain it, if it wants to keep a reference.

The stack nature of blocks does have some pitfalls, though. For example, this code is broken:

1
    void (^block)();
2
    if(x)
3
    {
4
        block = ^{ printf("x\n"); };
5
    }
6
    else
7
    {
8
        block = ^{ printf("not x\n"); };
9
    }
10
    block();

1
    [dictionary setObject: ^{ printf("hey hey\n"); } forKey: key];

The speed and simplicity of stack objects are a great boon for blocks, but it also creates a whole new class of bugs for unwary programmers.

Conclusion That wraps things up for this week. Come back in seven days for another exciting post. Until then, keep those suggestions coming. My material comes from user ideas, so if you have a topic you would like to see discussed here, send it in!