Universal Adapter for Native Calling Across ABIs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional adapters for calling native methods are inflexible and inefficient, as they are typically hard-coded for specific ABIs and memory structures, making them difficult to adapt to evolving technologies and multiple execution environments, such as compiled and interpreted modes.

Innovation Solution

A universal adapter system that generates intermediate instructions for memory manipulations, using instructions like SKIP, PULL, STOP, CREATE_BUFFER, and PULL_BUFFER_LABEL, which can be compiled or interpreted to handle various ABIs and memory structures, allowing for efficient native calls across different platforms.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If conventional adapters are hard-coded for specific ABIs and memory structures, then they provide stable and reliable native calling for a particular platform, but they lack adaptability to evolving technologies and multiple execution environments

Engineering Contradiction:
Improveadaptability to different ABIs and execution environmentsVSAvoidcomplexity of adapter implementation
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal adapter system that can function across multiple ABIs and execution environments (compiled and interpreted modes) through a single implementation. The adapter uses an intermediate instruction set that can be targeted to different platforms, eliminating the need for separate hard-coded adapters for each environment while maintaining adaptability to evolving technologies.

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

Solution Approach 2:

The patent introduces an intermediate instruction set as a mediator layer between the high-level adapter logic and platform-specific implementations. This intermediate layer allows the adapter to generate platform-appropriate code without being hard-coded to any specific ABI, enabling flexibility while simplifying the overall adapter structure through separation of concerns.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If conventional adapters are hard-coded for specific platforms, then they provide optimized performance for that platform, but they require frequent updates to support new technologies

Engineering Contradiction:
Improvesupport for evolving technologiesVSAvoidtime for updates and maintenance
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent implements a dynamic adapter system where the adapter behavior is determined at runtime based on the target platform and execution mode rather than being statically hard-coded. The system can dynamically generate or select appropriate intermediate instructions for different ABIs and platforms, allowing it to adapt to new technologies without requiring frequent updates to the core adapter logic.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent performs preliminary generation of intermediate instructions that can be later compiled or interpreted based on the target environment. By preparing the adapter logic in advance in an environment-independent intermediate form, the system eliminates the need for frequent updates when new platforms emerge, as the same intermediate representation can be targeted to different destinations.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If a universal adapter system is implemented to support multiple ABIs and execution modes, then adaptability improves, but the device complexity increases

Engineering Contradiction:
Improvecompatibility across platformsVSAvoidcomplexity of universal adapter system
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the adapter system into distinct layers: a high-level adapter generation component, an intermediate instruction set layer, and platform-specific compilation/interpretation layers. This segmentation isolates complexity into manageable sections, where each layer has a specific responsibility, making the overall universal system easier to maintain and understand despite its broad capabilities.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent replaces the mechanical approach of hard-coding separate adapters for each platform with a more abstract system based on intermediate representations and dynamic code generation. This substitution reduces complexity by eliminating the need for manual adaptation logic for each platform while maintaining universal compatibility through systematic code transformation.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

4Productivity

If intermediate instructions are used for memory manipulations, then the adapter can be compiled or interpreted for efficient execution, but the instruction set complexity increases

Engineering Contradiction:
Improveexecution efficiencyVSAvoidcomplexity of intermediate instruction set
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent changes the parameter representation by using an intermediate instruction set with standardized memory manipulation operations (SKIP, PULL, STOP, CREATE_BUFFER, PULL_BUFFER_LABEL) that can be parameterized for different platforms. This allows the same instruction template to be efficiently compiled or interpreted for various ABIs without requiring complex platform-specific logic, improving productivity while managing instruction set complexity through parameterization.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS10452409B2Universal adapter for native calling
Publication Date: 2019.10.22 ORACLE INT CORP
  • US10452409B2 patent drawing
  • US10452409B2 patent drawing
  • US10452409B2 patent drawing

AI summary

In one approach, a native call is performed using an adapter generator to produce an adapter for converting memory structures between a first memory representation adhering to a first application binary interface (ABI) and a second memory representation adhering to a second memory representation adhering to a second ABI. In some cases, the adapter produced by the adapter generator is stored in an adapter cache and indexed by the shape of the call for later reuse should the same native call be made again in the future. The adapter produced by the adapter generator uses a set of intermediate instructions which can be either compiled by a Just-in-Time (JIT) compiler or interpreted by an interpreter to produce executable instructions for converting between the first ABI and the second ABI.