Inside Macintosh: Mac OS Runtime Architectures /

Chapter 1 - CFM-Based Runtime Architecture

The Structure of Fragments

Every fragment can contain separate code and data sections. A code or data section can be up to 4 GB in size. Code and data sections do not have to be contiguous in memory.

Note

Since all fragments can contain both code and data sections, any fragment can contain global variables.

A code section contains position-independent executable code (that is, code that is independent of its own memory location and the location of its associated data). Code sections are read-only, so fragments can be stored in ROM or file-mapped and paged in from disk as necessary.

A data section is typically allocated in the application heap. Each data section may be instantiated multiple times, creating a separate copy for each connection associated with the fragment. See "Closures," beginning on page 1-6, for more details. An import library's data section may also be placed into the system heap or temporary memory (when systemwide instantiation is selected).

Although a fragment's code and data sections can be located anywhere in memory, those sections cannot be moved within memory once they are prepared. The Code Fragment Manager must resolve any dependencies a fragment might have on other fragments, and this preparation involves placing pointers to imported code and data into the fragment's data section. To avoid having to prepare fragments in this way more than once, the Mac OS requires that a prepared fragment remain stationary as long as it stays in memory.

Note

Accelerated resources, which model the behavior of classic 68K resources, do not have to be fixed in memory between calls.

---

Subtopics

Fragment Storage

The Code Fragment Resource

Special Symbols