Clarification on Where Application Code and Static Libraries Are Stored in Memory

Question

EricKwon OP

Created Jun ’24

Replies 1

Boosts 0

Participants 2

Hello,

I’m seeking some clarity regarding the memory storage of application code and static libraries.

I understand the basic memory layout in terms of the code (text) segment, data segment, heap, and stack:

•	Code Segment (Text Segment): Typically stores the compiled program code.
•	Data Segment: Stores global and static variables.
•	Heap: Dynamically allocated memory during runtime.
•	Stack: Stores local variables and function call information.

However, I’ve come across some conflicting information:

1.	Official Documentation: In an illustration from Apple’s official documentation, it appeared as though application code might be stored in the heap. This seemed unusual given my understanding that compiled code is generally stored in the code segment.

Address Space 1.png from document archive

2.	Blog Posts: Several blogs mention that the source code for static libraries is stored in the heap. This also contradicts my understanding since static libraries, after being linked, should be part of the application’s executable code, thus residing in the code segment.

Given these points, my understanding is that:

•	Application Code: After compilation, the executable code should be stored in the code segment.
•	Static Libraries: Once linked, the code from static libraries should also be part of the code segment.

Could you please clarify:

•	Where exactly is the application code stored in memory?
•	Is the claim that static libraries’ source code is stored in the heap correct, or is it a misunderstanding?

Thank you!

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’24

Accepted Answer

Recommended

Let’s start with some basics. There are two sources of executable code:

Mach-O images that have been memory mapped into your address space.
Code generating on the fly via JITing.

If you define “heap” as “address space allocated using malloc” then:

The first is most definitely not in the heap.
The second might be in the heap, but it’s usually not.

In an illustration from Apple’s official documentation, it appeared as though application code might be stored in the heap. This seemed unusual given my understanding that compiled code is generally stored in the code segment.

Yeah, I can see how you’d be misled by that diagram. If I had drawn it, I’d put “Heap” into its own bubble, just like “Stack”.

[quote='756530021, EricKwon, /thread/756530, /profile/EricKwon']

Blog Posts: Several blogs mention that the ~~source~~ executable code for static libraries is stored in the heap.

Blog Posts: Several blogs mention that the ~~source~~ executable code for static libraries is stored in the heap.

However, you’re correct that, in the typical case:

The static linker merges a static library into a Mach-O image.
The dynamic linker memory maps that Mach-O image into the process’s address space.

You can prove this for yourself with some readily available tools. Consider this program:

@import Foundation;

int main(int argc, char **argv) {
    void * heap = malloc(1024);
    fprintf(stdout, "Hello Cruel World!, main: %p, heap: %p, pid: %d\n", main, heap, (int) getpid());
    (void) getchar();
    return EXIT_SUCCESS;
}

Run it from Terminal like so:

% ./TestAddressMap
Hello Cruel World!, main: 0x1042c3e6c, heap: 0x11e808c00, pid: 76182

and then run vmmap against that process:

% vmmap -interleave 76121
…
__TEXT          1042c0000-1042c4000 … /Users/…/TestAddressMap
…
MALLOC_SMALL    11e800000-11f000000 … MallocHelperZone_0x104728000

That generates a lot of output but, if you look through the map you’ll see:

The address of main (0x1042c3e6c) falls within the TestAddressMap Mach-O executable that was memory mapped into the process.
The heap pointer (0x11e808c00) falls within a MALLOC_SMALL area.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1