Dynamic Survivor Memory Allocation for Garbage Collection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing memory management systems for software applications require dedicated survivor memory for each application, which is not available for data storage and consumes memory unnecessarily, especially in systems with many applications and large memory allocations.

Innovation Solution

A method where a memory manager supplies a first allocation space for data storage and discards inactive data by identifying active data, copying it to a second unit of memory, indicating its inactivity, and mapping the first allocation space to be logically contiguous with the second unit, thereby releasing the remaining portion for reuse, allowing survivor memory to be used only during garbage collection.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If dedicated survivor memory is allocated for each software application, then garbage collection can be performed effectively, but memory is wasted as it is not available for data storage when not currently performing garbage collection

Engineering Contradiction:
Improvegarbage collection effectivenessVSAvoidmemory usage efficiency
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The survivor memory is made dynamic by allocating it on-demand during garbage collection operations rather than statically allocating dedicated survivor memory for each application. The memory manager dynamically supplies survivor memory from available memory pools when garbage collection is needed, and reclaims it when not needed, making the memory usage adaptive to actual operational requirements.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The same memory pool serves multiple purposes: it acts as general allocation space for applications during normal operation and as survivor memory during garbage collection operations. The memory manager universalizes the memory resource by allowing it to function as both application data storage and garbage collection survivor space at different times, eliminating the need for dedicated survivor memory regions.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If survivor memory is reserved for use during garbage collection, then active data can be copied and retained, but the reserved memory is not available for storage of data by software applications

Engineering Contradiction:
Improvedata retention during garbage collectionVSAvoidavailable memory for application data
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The boundary between application allocation space and survivor memory is made dynamic rather than fixed. During garbage collection, the memory manager dynamically designates portions of the memory pool as survivor memory, and this designation changes based on operational needs. This dynamic reconfiguration allows the same physical memory to serve different logical purposes at different times.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The memory allocation scheme operates periodically with garbage collection cycles. During normal operation, memory is allocated to applications; during garbage collection periods, survivor memory is temporarily reserved; after garbage collection, the memory is returned to the general pool. This periodic switching between modes allows both application data storage and garbage collection to function effectively without permanent memory reservation.

Inventive Principle:
Principle #19Periodic action

3Ease of operation

If each application maintains its own survivor memory, then garbage collection can be performed independently, but in systems with many applications the total survivor memory consumption becomes excessively large

Engineering Contradiction:
Improveindependent garbage collectionVSAvoidtotal survivor memory consumption
Core Design Contradiction:
Ease of operationVSQuantity of substance

Solution Approach 1:

The patent merges the survivor memory functions of multiple applications into a shared memory pool managed by the memory manager. Instead of each application maintaining separate survivor memory regions, the memory manager consolidates survivor memory needs and supplies memory from a common pool during garbage collection operations. This combining approach maintains independent garbage collection capability while dramatically reducing total memory consumption in multi-application systems.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The memory manager acts as an intermediary between applications and physical memory, mediating the survivor memory allocation. When an application needs to perform garbage collection, the memory manager supplies survivor memory from the available pool rather than the application allocating its own. This intermediary role allows coordinated memory management across multiple applications, reducing total survivor memory consumption while maintaining independent garbage collection operations.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2225646B1Memory management
Publication Date: 2011.08.10 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • EP2225646B1 patent drawingFigure 1a~1b
  • EP2225646B1 patent drawingFigure 2
  • EP2225646B1 patent drawingFigure 3a~3b

AI summary

A method of memory management for a software application in execution in a computer system, the method comprising the steps of: a memory manager supplying a first unit of memory having a predetermined size as a first allocation space for the software application; the software application storing data in the first allocation space; and discarding inactive data in the first allocation space by the steps of: a) the memory manager supplying a second unit of memory for the software application; b) identifying active data in the first allocation space and copying said active data to the second unit of memory, the active data including at least data that is in use by the software application; c) indicating, in the first allocation space, that the active data has become inactive; d) mapping a portion of the first allocation space to be logically contiguous with the second unit of memory to define a second allocation space for the software application whereby the second allocation space has a size that is equivalent to the predetermined size; and e) returning a remaining portion of the first allocation to the memory manager as a unit of memory suitable for reuse.