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.
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!
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
sourceexecutable 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 theTestAddressMapMach-O executable that was memory mapped into the process. -
The
heappointer (0x11e808c00) falls within aMALLOC_SMALLarea.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"