Shared-Memory Deallocation Across Trust Boundaries Without Cross-Domain Calls
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cross-domain communication mechanisms across trust boundaries in software components are expensive in terms of compute cycles and introduce latency, making it difficult to efficiently deallocate memory across these boundaries.
Innovation Solution
Implement an in-memory message passing facility using shared memory to enable efficient memory deallocation by separating the deallocation process into marking memory as unused and making it available for reuse, with validation checks to ensure memory access is within the shared memory region.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If cross-domain communication mechanism is used to deallocate memory across trust boundary, then memory deallocation can be achieved, but compute cycles increase and latency is introduced
Solution Approach 1:
The deallocation process is segmented into two independent phases: (1) marking memory as unused by the deallocating software component, and (2) making memory available for reuse by the allocating software component. This segmentation allows the first phase to execute locally without cross-domain communication, while the second phase can proceed asynchronously, eliminating the latency bottleneck of traditional synchronous cross-domain deallocation.
Solution Approach 2:
The marking phase is performed as a preliminary action before the memory becomes available for reuse. By completing the marking operation locally first, the system prepares memory for deallocation without waiting for cross-domain communication, thereby reducing overall deallocation time and improving productivity.
2Productivity
If cross-domain communication mechanism is used to deallocate memory across trust boundary, then memory deallocation can be achieved, but compute cycles increase
Solution Approach 1:
The computationally intensive cross-domain communication step is extracted and removed from the deallocation process. Instead of performing deallocation through expensive cross-domain calls, the system extracts the marking operation to be executed locally, eliminating the need for costly cross-domain communication while maintaining memory deallocation functionality.
Solution Approach 2:
The marking phase is performed as a self-service operation by the deallocating software component itself, without requiring assistance from the allocating software component. This self-service approach eliminates the need for cross-domain communication and reduces compute cycle consumption while achieving memory deallocation.
3Speed
If local deallocation mechanism is used without validation, then deallocation speed increases, but memory access security is compromised
Solution Approach 1:
Validation checks act as an intermediary between the local deallocation mechanism and the shared memory region. These checks verify that memory access remains within the shared memory boundaries, enabling fast local deallocation while maintaining security through a lightweight validation layer that prevents unauthorized memory access.
Data Source
Figure 1
Figure 2A~2D
Figure 3
AI summary
A method of memory deallocation across a trust boundary between a first software component and a second software component is described. Some memory is shared between the first and second software components. An in-memory message passing facility is implemented using the shared memory. The first software component is used to deallocate memory from the shared memory which has been allocated by the second software component. The deallocation is done by: taking at least one allocation to be freed from the message passing facility; and freeing the at least one allocation using a local deallocation mechanism while validating that memory access to memory owned by data structures related to memory allocation within the shared memory are within the shared memory.