Runtime Object Identity Hash Generation via Nonce Mixing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for generating object identifiers in runtime environments are vulnerable to security breaches due to predictable incremental seed values and are prone to hash collisions as the counter overflows, leading to inefficient computational performance.

Innovation Solution

The proposed solution involves deriving object identifiers by mixing and hashing seed values with nonce values and salt values, which are unique per allocation region, ensuring unpredictable identifiers and minimizing hash collisions by dynamically adjusting identifier lengths based on the number of objects in the runtime environment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If incremental seed values are used for generating object identifiers, then the generation process is simple and efficient, but the identifiers become predictable and vulnerable to security breaches

Engineering Contradiction:
Improveidentifier generation efficiencyVSAvoidsystem security
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent changes the parameters used in identifier generation from simple incremental counters to a combination of hash functions applied to multiple parameters including object class, allocation region, and offset. This transformation maintains generation efficiency while producing unpredictable identifiers that enhance security.

Inventive Principle:
Principle #35Parameter changes

2Device complexity

If a global counter is used to generate seed values, then the implementation is straightforward, but hash collisions increase when the counter overflows

Engineering Contradiction:
Improveimplementation complexityVSAvoidhash collision probability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The patent segments the identifier generation process into multiple independent components: hash function selection, object class identification, allocation region identification, and offset calculation. This segmentation eliminates the need for a global counter while distributing the identifier space across multiple dimensions, thereby reducing hash collision probability.

Inventive Principle:
Principle #1Segmentation

3Quantity of substance

If fixed-length identifiers are used, then storage is efficient, but the system cannot adapt to varying numbers of objects in the runtime environment

Engineering Contradiction:
Improvestorage efficiencyVSAvoidsystem adaptability
Core Design Contradiction:
Quantity of substanceVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic identifier length adjustment based on the number of objects in the runtime environment. The system monitors object count and adjusts identifier length accordingly, using shorter identifiers when object count is low for storage efficiency, and longer identifiers when object count increases to maintain uniqueness and reduce collisions.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS20230367638A1Computation and Storage of Object Identity Hash Values
Publication Date: 2023.11.16 ORACLE INT CORP
  • US20230367638A1 patent drawing
  • US20230367638A1 patent drawing
  • US20230367638A1 patent drawing

AI summary

Techniques for computing and storing object identity hash values are disclosed. In some embodiments, a runtime system generates a value, such as a nonce, that is unique to a particular allocation region within memory. The runtime system may mix the value with one or more seed values that are associated with one or more respective objects stored in the allocation region. The runtime system may obtain object identifiers for the respective objects by applying a hash function to the result of mixing the seed value with at least the value associated with the allocation region. Conditioning operations may also be applied before, during or after the mixing operations to make the values appear more random. The nonce value may be changed from time to time, such as when memory is recycled in the allocation region, to reduce the risk of hash collisions.