📝 Dynamic memory loading in Main memory (9 MCQs)
📖 From Operating System • 8. Main Memory • 9 questions available
What is Dynamic memory loading in Main memory?
Definition:
Dynamic loading defers loading of routines until they are called at runtime keeping unused code out of main memory to conserve space.
Example:
A graphics application loads the JPEG decoder library only when is invoked rather than including it in the initial executable image.
Reason:
This technique reduces memory footprint and startup time especially beneficial for large applications with many optional features that may never execute.
📝 All Dynamic memory loading in Main memory MCQs
Q1. What is dynamic loading?
📖 Explanation: Dynamic loading is a technique where the operating system brings a module into RAM only when the program first needs it. Option A describes this behavior. Option B describes static loading, which loads everything at start. Option C is unrelated to loading, and Option D confuses compilation with loading. Understanding this definition helps students recognize why programs can start faster and use less memory.
Q2. Why does dynamic loading typically improve memory utilization compared to static linking?
📖 Explanation: Dynamic loading keeps code that a program never calls on disk, so only the needed portions occupy RAM. Option B correctly states that only required code is loaded, reducing RAM usage. Option A is partially true but does not explain the mechanism. Options C and D describe unrelated concepts. Recognizing this benefit explains why many modern applications prefer dynamic loading.
Q3. A graphics application can load a plug‑in at runtime to add new filters. Which step is essential for the plug‑in to become usable?
📖 Explanation: The operating system’s loader must map the plug‑in’s binary into the running process, allowing the program to call its functions. Option C captures this essential step. Option A would require a JIT compiler, which is not typical for binary plug‑ins. Option B defeats the purpose of dynamic loading, and Option D is unrelated to loading. This scenario shows how dynamic loading enables extensibility without rebuilding the main program.
Q4. When a program requests a symbol from a shared library during dynamic loading, which component resolves the symbolic address to a physical memory location?
📖 Explanation: During dynamic loading, the runtime dynamic linker/loader examines the library’s symbol table and patches the program’s references, turning symbolic names into actual memory addresses. Option D correctly identifies this component. The CPU decoder (A) works after addresses are known, the optimizer (B) runs at compile time, and the disk controller (C) merely moves data. Knowing the role of the dynamic linker clarifies how symbols become usable after load time.
Q5. How does dynamic linking relate to the concept of shared libraries?
📖 Explanation: Dynamic linking works hand‑in‑hand with shared libraries: the library remains a single copy in memory, and each process that loads it at runtime shares that copy. Option A correctly describes this relationship. Option B mistakenly suggests copying, which would waste memory. Options C and D are inaccurate. Understanding this link explains why shared libraries reduce overall memory consumption while still providing modular code.
Q6. A program statically links a 10 MB library but only uses 2 MB of its functions. If the same library is dynamically loaded, how much memory could be saved?
📖 Explanation: When statically linked, the entire 10 MB library occupies RAM even if only 2 MB is needed. Dynamic loading brings in only the required 2 MB, leaving the remaining 8 MB on disk. Thus the saved memory is . Option B reflects this calculation. Options A and C give incorrect amounts, and D ignores the benefit of dynamic loading. This calculation illustrates the tangible memory savings dynamic loading can provide.
Q7. During execution, a program crashes with a “cannot locate symbol X” error. Which situation most likely caused this?
📖 Explanation: A missing‑symbol error at runtime typically means the loader could not resolve the reference, often because the symbol name does not match (renamed) or the library was not loaded. Option C directly addresses a rename mismatch, which is the most common cause. Options A and B would cause compile‑time or load‑time failures, not a runtime symbol error. Option D is unrelated to symbol resolution. Recognizing the cause helps developers troubleshoot dynamic loading problems.
Q8. What is lazy binding in the context of dynamic loading, and how does it affect program startup time?
📖 Explanation: Lazy binding postpones the resolution of each external symbol until the first time the program actually calls it, which shortens the initial loading phase. Option B captures this behavior. Option A describes eager binding, which lengthens startup. Option C is unrelated to binding strategy, and Option D eliminates dynamic linking. Understanding lazy binding explains why some programs start quickly but may incur a small delay on first use of a function.
Q9. A program uses logical addresses while executing. When the operating system moves its code segment to a different physical frame, which type of address does the program continue to use?
📖 Explanation: The program operates with logical (virtual) addresses; the OS translates them to physical frames via paging or segmentation. Even if the code moves to a new physical frame, the program still references logical addresses, and the hardware mapping updates transparently. Option A is correct. Physical, disk block, and absolute addresses are not exposed to the running program. This distinction shows why dynamic loading can relocate code without requiring changes in the program’s address references.