Shared Object Region for Cross-Isolate Java Data Exchange

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In Java programming, sharing objects between isolates is challenging due to type safety mechanisms and memory management, as isolates have private memory areas, and objects created by one isolate cannot be used by another unless both isolates are executing concurrently, and class loaders vanish upon termination.

Innovation Solution

A shared object region is created in memory with a shared class loader, allowing multiple isolates to access and understand the class type of objects stored within, enabling object sharing without requiring concurrent execution of the isolates that created them.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If isolates use private memory areas for object storage, then type safety and isolation are ensured, but object sharing between isolates becomes impossible

Engineering Contradiction:

Improvetype safetyVSAvoidobject sharing capability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The memory space is segmented into private isolate heap areas and a shared object region. Objects are segmented into those stored privately (for isolation) and those stored in the shared region (for interoperability). This segmentation allows type safety within isolates while enabling controlled sharing across isolate boundaries through the shared region.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The shared object region acts as an intermediary between isolates. Instead of isolates directly sharing memory (which would compromise type safety), they interact through this intermediate shared region where objects can be stored and referenced by multiple isolates with proper type checking.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If class loaders are privately defined by each isolate, then type safety is maintained, but objects created by one isolate cannot be understood by another isolate

Engineering Contradiction:

Improvetype safetyVSAvoidcross-isolate object usability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The shared class loader is designed to serve multiple isolates simultaneously. It can load and define classes that are visible to and usable by any isolate attached to the shared object region, making the class loader universal rather than isolate-specific. This enables objects created by one isolate to be understood by others through the shared class definitions.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The shared class loader acts as an intermediary for class definition and resolution. Instead of each isolate having its own private class loader, the shared class loader mediates class loading and definition for all isolates accessing the shared object region, ensuring consistent type understanding across isolate boundaries.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Reliability

If isolates execute independently with private memory, then isolation and security are ensured, but concurrent execution is required for object access

Engineering Contradiction:

ImproveisolationVSAvoidobject access simplicity

Core Design Contradiction:

ReliabilityVSEase of operation

Solution Approach 1:

The system segments object storage into private isolate heaps and a shared object region. Objects intended for cross-isolate access are placed in the shared region, while isolate-specific objects remain in private memory. This segmentation allows isolates to access shared objects without requiring the creating isolate to remain active, as the shared region maintains object persistence independently of any single isolate's execution state.

Inventive Principle:

Principle #1Segmentation

4Adaptability or versatility

If objects are stored in shared memory area, then sharing is enabled, but type safety mechanisms prevent incompatible operations

Engineering Contradiction:

Improveobject sharingVSAvoidtype checking complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The shared class loader acts as an intermediary that performs type checking and validation for objects in the shared region. It ensures that only type-compatible operations are performed on shared objects, maintaining type safety while enabling sharing. The shared class loader verifies type compatibility before allowing operations, reducing the complexity burden on individual isolates.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS7840967B1Sharing data among isolated applications

Publication Date: 2010.11.23 ORACLE AMERICAN INC

AI summary

A technique for allowing isolated JAVA applications (“isolates”) to share data between themselves is disclosed. According to one aspect, a shared object region, to which multiple isolates may attach, is defined in memory. A shared class loader associated with the region is stored in the region in conjunction with the region's creation. Isolates that can access the region can invoke that loader. The region only comprises objects whose type is defined by a bootstrap class loader or the region's associated shared class loader. Runtime representations of classes defined by the shared class loader are stored in the region. Thus, the types of objects stored in the region are known to all isolates that attach to the region. Isolates attached to the region may enter the context of the region to access objects stored therein. Within the context of a shared object region, all allocation instructions automatically allocate to that region.