An asynchronous method is implemented in a manner that reduces the amount of runtime overhead needed to execute the asynchronous method. The data elements needed to suspend an asynchronous method to await completion of an asynchronous operation, to resume the asynchronous method at a resumption point, and to provide a completion status of the caller of the asynchronous method are consolidated into one or two reusable objects. An asynchronous method may be associated with a distinct object pool of reusable objects. The size of a pool and the total size of all pools can be configured statically or dynamically based on runtime conditions.

A compilation system can define, at compile time, the data blocks to be managed by an Even Driven Task (EDT) based runtime/platform, and can also guide the runtime/platform on when to create and/or destroy the data blocks, so as to improve the performance of the runtime/platform. The compilation system can also guide, at compile time, how different tasks may access the data blocks they need in a manner that can improve performance of the tasks.

A system software and method which relates to the field of computing technology or business process models or computer systems or distributed computer systems or computer networks relating to general purpose devices that can be programmed to carry out a set of data table or hash table updates, validations or modifications supporting, enabling or executing public and private services, financial transactions and commercial applications. More specifically, the present invention is directed to distributed and decentralized computing in which said distributed network is supported and encrypted by cryptographic technology, hash functions and distributed public or private keys or other related technology. System and methods for managing dynamic electronic documents on a private distributed ledger comprise establishing a dynamic electronic document comprising a first state object, wherein the state object references a prior approved first transaction; proposing a second transaction comprising as an input the first state object and as an output a transaction command to alter the state object as well as what parameters are required to validate the second transaction; validating the proposed second transaction; and updating the state object on a private distributed ledger to reference the second transaction.

Adaptive data collections may include various type of data arrays, sets, bags, maps, and other data structures. A simple interface for each adaptive collection may provide access via a unified API to adaptive implementations of the collection. A single adaptive data collection may include multiple, different adaptive implementations. A system configured to implement adaptive data collections may include the ability to adaptively select between various implementations, either manually or automatically, and to map a given workload to differing hardware configurations. Additionally, hardware resource needs of different configurations may be predicted from a small number of workload measurements. Adaptive data collections may provide language interoperability, such as by leveraging runtime compilation to build adaptive data collections and to compile and optimize implementation code and user code together. Adaptive data collections may also provide language-independent such that implementation code may be written once and subsequently used from multiple programming languages.

A technique for operating a computer system to support an application, a first application server environment, and a second application server environment includes intercepting a work request relating to the application issued to the first application server environment prior to execution of the work request. A thread adapted for execution in the first application server environment is created. A context is attached to the thread that non-disruptively modifies the thread into a hybrid thread that is additionally suitable for execution in the second application server environment. The hybrid thread is returned to the first application server environment.

According to an example, machine readable instructions backward compatibility may include determining changes between first and second sets of machine readable instructions, and generating a backward compatibility switch. The backward compatibility switch may be implemented in the second set of machine readable instructions to selectively revert functionality to functionality of the first set of machine readable instructions.

In an embodiment, dynamically-generated code may be supported in the system by ensuring that the code either remains executing within a predefined region of memory or exits to one of a set of valid exit addresses. Software embodiments are described in which the dynamically-generated code is scanned prior to permitting execution of the dynamically-generated code to ensure that various criteria are met including exclusion of certain disallowed instructions and control of branch target addresses. Hardware embodiments are described in which the dynamically-generated code is permitted to executed but is monitored to ensure that the execution criteria are met.

Techniques are disclosed for eliding load and store barriers while maintaining garbage collection invariants. Embodiments described herein include techniques for identifying an instruction, such as a safepoint poll, that checks whether to pause a thread between execution of a dominant and dominated access to the same data field. If a poll instruction is identified between the two data accesses, then a pointer for the data field may be recorded in an entry associated with the poll instruction. When the thread is paused to execute a garbage collection operation, the recorded information may be used to update values associated with the data field in memory such that the dominated access may be executed without any load or store barriers.

Some embodiments provide a non-transitory machine-readable medium that stores a program. The program observes a parameter associated with a computing system. Upon receiving a change associated with the parameter, the program further determines a routine definition from a set of routine definitions associated with the parameter. Each routine definition in the set of routine definitions specifies a set of instructions associated with a particular parameter associated with the computing system. The program also executes the set of instructions specified in the determined routine definition.

Disclosed embodiments relate to encoded inline capabilities. In one example, a system includes a trusted execution environment (TEE) to partition an address space within a memory into a plurality of compartments each associated with code to execute a function, the TEE further to assign a message object in a heap to each compartment, receive a request from a first compartment to send a message block to a specified destination compartment, respond to the request by authenticating the request, generating a corresponding encoded capability, conveying the encoded capability to the destination compartment, and scheduling the destination compartment to respond to the request, and subsequently, respond to a check capability request from the destination compartment by checking the encoded capability and, when the check passes, providing a memory address to access the message block, and, otherwise, generating a fault, wherein each compartment is isolated from other compartments.