CN112214424B

CN112214424B - Object memory architecture, processing node, memory object storage and management method

Info

Publication number: CN112214424B
Application number: CN202010856998.0A
Authority: CN
Inventors: S.弗兰克; L.里巴克
Original assignee: Ultrata LLC
Current assignee: Ultrata LLC
Priority date: 2015-01-20
Filing date: 2016-01-20
Publication date: 2024-04-05
Anticipated expiration: 2036-01-20
Also published as: US20220137818A1; EP3248106A4; US9971506B2; WO2016118630A1; US20180225046A1; WO2016118591A1; US9965185B2; US20160210238A1; WO2016118607A1; CA2974394A1; EP3998526A1; US11775171B2; US20160210082A1; US20160210054A1; US10452268B2; CN107533518A; US11126350B2; CN112214424A; EP3248106A1; US20180217755A1

Abstract

The invention relates to an object memory architecture, a processing node, a memory object storage and management method. The object memory fabric includes a hierarchy of a plurality of object memory modules and an object router communicatively coupled to the plurality of object memory modules. Each object memory module comprises a single pluggable hardware module and an object memory bank for storing memory objects, memory object metadata and memory module object catalogs, and each memory object and/or part of each memory object is locally created in the object memory module and locally managed in a single memory layer; the memory module object directory indexes all memory objects and/or portions thereof within the object memory module; each object router maintains an object cache state for memory objects and/or portions thereof contained in the underlying object memory module; based on the object cache state, the hierarchy of object routers is communicatively coupled to a single object directory of all object memory modules and processes requests.

Description

Object memory architecture, processing node, memory object storage and management method

The present application is a divisional application of the invention patent application with the application date of 2016, 1-20, the application number of 201680015942.4 (International application number of PCT/US 2016/014099) and the name of "distributed index for fault tolerant object memory structure".

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional application No.62/105,602 under 35USC 119 (e), filed by Frank et al at month 20 of 2015, entitled "Infinite Memory Fabric Data Types and Metadata Architecture," the entire disclosure of which is incorporated herein by reference for all purposes.

The present application also relates to the following co-pending and commonly assigned U.S. patent applications:

the title "Object Based Memory Fabric" was filed by Frank on day 1, month 20 of 2016U.S. patent application No.15/001,320；

U.S. patent application No. entitled "Trans-Cloud Object Based Memory" filed by Frank on day 1 and 20 of 2016.15/001,322；

U.S. patent application No. entitled "Universal Single Level Object Memory Address Space" filed by Frank on day 1 and 20 of 2016.15/001,340；

U.S. patent application No. entitled "Object Memory Fabric Performance Acceleration" filed by Frank on day 1 and 20 of 2016. 15/001,343；

U.S. patent application No. entitled "Implementation of an Object Memory Centric Cloud" filed by Frank on day 1 and 20 of 2016.15/001,494；

U.S. patent application No. entitled "manufacturing Meta-Data in an Object Memory Fabric" filed by Frank on day 1 and 20 of 2016.15/001,524；

U.S. patent application No. entitled "Utilization of a Distributed Index to Provide Object Memory Fabric Coherency" filed by Frank on day 1 and 20 of 2016.15/001,652；

U.S. patent application No. entitled "Object Memory Data Flow Instruction Execution" filed by Frank on day 1 and 20 of 2016.15/001,366；

U.S. patent application No. entitled "Object Memory Data Flow Trigger" filed by Frank on day 1 and 20 of 2016.15/001,490The method comprises the steps of carrying out a first treatment on the surface of the And

U.S. patent application No. entitled "Object Memory Instruction Set" filed by Frank on day 1 and 20 of 2016.15/001,526The entire disclosure of each of which is incorporated herein by reference for all purposes.

Background

Embodiments of the present invention relate generally to methods and systems for improving performance of processing nodes in a fabric, and more particularly, to changing the manner of management processing (processing), memory, storage, networking, and cloud computing to significantly improve efficiency and performance of commodity hardware.

As the size and complexity of data and processes performed thereon continue to increase, computer hardware is challenged to meet these requirements. Current commodity hardware and software solutions from existing servers, networks, and storage suppliers fail to meet the demands of cloud computing and big data environments. This is due, at least in part, to the manner in which these systems manage processes, memory, and banks. Specifically, in current systems, the process is separate from the memory, which in turn is separate from the memory bank, each of which is managed by software separately. Each server and other computing device (referred to herein as a node) is in turn separated from other nodes by a physical computer network, they are managed individually by software, and in turn, the individual processes, memories, and banks associated with each node are managed by software on that node.

Fig. 1 is a block diagram illustrating an example of separate data storage, memory and processing within a prior art commodity server and network element. This example shows a system 100 in which commodity servers 105 and 110 are communicatively coupled to each other via a physical network 115 and network software 155 as known in the art. It is also known in the art that the servers may each execute any number of one or more applications 120a, 120b, 120c of any kind. As is known in the art, each application 120a, 120b, 120c is executed on a processor (not shown) and memory (not shown) of servers 105 and 110 using data stored in physical storage 150. Each of the servers 105 and 110 maintains a directory 125 that maps the locations of the data used by the applications 120a, 120b, 120c. In addition, each server implements a software stack for each executing application 120a, 120b, 120c that includes an application representation 130 of data, a database representation 135, a file system representation 140, and a storage volume representation 145.

While effective, there are three reasons that the implementation of these current commodity hardware and software solutions from existing server, network and storage suppliers is not satisfactory for the ever-increasing demands of cloud computing and big data environments. One reason for the drawbacks of these implementations is their complexity. The software stack must be in place and each application must manage the separation of memory banks, memory and processing, as well as the application parallel server resources. Each application must trade off algorithm parallelism, data organization, and data movement, which is very challenging for correctness, let alone performance and economy considerations. This tends to result in more batch oriented solutions being implemented in the application than the integrated real-time solutions preferred by most businesses. Furthermore, the separation of memory banks, memory and processing in such an implementation also creates significant inefficiencies in finding, moving and accessing data blocks for each layer of the software stack due to the required instruction execution, and delays for each layer of the software stack and between layers. In addition, this inefficiency limits the economic scale possibilities and limits the data size of all but the most parallel algorithms. The reason for the latter is that the efficiency with which the servers (processors or threads) can interact limits the degree of parallelism due to the armful law (amahl's law). Accordingly, there is a need for improved methods and systems for managing processes, memory, and banks, thereby significantly improving the performance of processing nodes.

Disclosure of Invention

Embodiments of the present invention provide systems and methods for managing processing, memory, and storage to significantly improve the performance of processing nodes. Some embodiments may include an object store structure distributed object store and an index. Using distributed indexing, individual nodes can index local objects and blocks of objects on a per object basis. Some embodiments of object store architecture distributed object stores and indexing may be based at least in part on overlaying a separate local index function at the top of a fat tree hierarchical network.

In one aspect, an object memory fabric is disclosed. The object memory fabric may include a plurality of object memory modules, each object memory module including an object store storing one or more memory objects, memory object metadata, and a memory module object directory. Each memory object and/or portion of a memory object may be created locally within the object memory module and may be managed by the object memory module at a memory layer. The memory module object directory may index all memory objects and/or portions of memory objects within the object memory module. The object memory fabric may include a hierarchy of object routers communicatively coupling a plurality of object memory modules. Each object router of the hierarchy of object routers may include a router object directory. The router object directory may index all memory objects and/or portions of memory objects contained in the object memory modules under the object router along a descent line (a line of descent) in the hierarchy originating from the object router. Based at least in part on the router object directory, the hierarchy of object routers is adapted to appear collectively as a single object directory communicatively coupled to all object memory modules, and to process requests based at least in part on the router object directory.

The hierarchical structure of object routers may operate according to a hierarchical tree network. The object memory modules under the object router along a descent line in the hierarchy originating from the object router include object memory modules communicatively coupled directly to the respective object router towards the leaves of the hierarchical tree network. The leaf toward the hierarchical tree network may correspond to the most direct path between the object router away from the root of the hierarchical tree network and the object memory module at the leaf of the hierarchical tree network.

An individual object directory, which appears as being communicatively coupled to all object memory modules, collectively, may include: in response to each of the requests, at least one of the object routers uses a respective router object directory to find an object corresponding to the request, and: forwarding the object to a leaf in the hierarchy after identifying that the reference to the object is in the corresponding router object directory; after identifying that the reference to the object is not in the corresponding router object directory, the first request is forwarded to a root in the hierarchy.

At least one of the requests may be received from an application layer. Each object memory module can also include an object index tree that indexes local memory objects. The object index tree may include node blocks and leaf blocks, each of which is distinguished by a type attribute, wherein one or more of the leaf blocks points to a location of a local memory object in persistent memory and/or higher speed memory. The object index tree may include pointers to each object index tree of each local memory object that index memory object data and memory object metadata that are presented locally to the local memory object on a block basis. Each object index tree may include node blocks and leaf blocks, each of which is distinguished by a type attribute, wherein one or more of the leaf blocks points to locations of memory object data and memory object metadata in persistent memory and/or higher speed memory. A hierarchy of object routers adapted to appear collectively as a single object directory may be used to manage at least one memory object across a number of object memory modules that do not have the storage space required to store all of the blocks of at least one memory object.

In another aspect, a hardware-based processing node is disclosed. The hardware-based processing node may include an object memory module including an object store storing one or more memory objects, memory object metadata, and a memory module object directory. Each memory object and/or portion of a memory object may be created locally within the object memory module and may be managed by the object memory module at a memory layer. The memory module object directory may index all memory objects and/or portions of memory objects within the object memory module. The object store module may process one or more requests based at least in part on one or more object directories.

Processing the one or more requests may include: processing an object identifier corresponding to a first request of the one or more requests; determining whether at least one of the one or more memory objects corresponds to the object identifier, and generating a response to the first request based at least in part on the at least one object after determining that at least one of the one or more memory objects does correspond to the object identifier. The object router may be communicatively coupled to an object memory module that routes the first request to the additional node after determining that at least one of the one or more memory objects does not correspond to the object identifier. Routing the first request to the additional node may be based at least in part on the object router determining that the location of the memory object corresponds to the object identifier. Routing the first request to the additional node may be based at least in part on the object router determining that a location of a memory object corresponding to the object identifier is unknown. The first request may be directed towards a root node. After routing the first request to the additional node, the memory module may generate a response to the first request based at least in part on the response received from the additional node. The object memory module may also include an object index tree that indexes local memory objects. The object index tree may include node blocks and leaf blocks, each of which is distinguished by a type attribute, wherein one or more of the leaf blocks points to a location of a local memory object in persistent memory and/or higher speed memory. The object index tree may include pointers to each object index tree of each local memory object that index memory object data and memory object metadata presented locally to the local memory object on a block basis. Each object index tree may include node blocks and leaf blocks, each of which is distinguished by a type attribute, wherein one or more of the leaf blocks points to locations of memory object data and memory object metadata in persistent memory and/or higher speed memory. At least one of the one or more requests may be received from an application layer. At least one of the one or more requests may be received from one or more additional nodes. The node may be configured to be operably coupled to one or more additional nodes using a set of algorithms to operate as a set of nodes and independent of the size of the set of nodes, wherein the set of nodes operate such that all memory objects of the set of nodes are accessible by any node in the set of nodes.

In yet another aspect, a method of storing and managing one or more memory objects in an object memory fabric is disclosed. The method may include any one or a combination of the following. One or more memory objects, memory object metadata, and memory module object directories may be stored in an object store of an object memory module. Each memory object and/or portion of a memory object may be created locally within the object memory module and may be managed by the object memory module at a memory layer. The memory module object directory may index all memory objects and/or portions of memory objects within the object memory module. The object store module may process one or more requests based at least in part on the one or more object directories.

Processing the one or more requests may include: processing an object identifier of a first request corresponding to the one or more requests; determining whether at least one of the one or more memory objects corresponds to the object identifier; and upon determining that at least one of the one or more memory objects does correspond to the object identifier, generating a response to the first request based at least in part on the at least one object. Processing the one or more requests may include routing the first request to an additional node through an object router communicatively coupled to the object memory module upon determining that at least one of the one or more memory objects does not correspond to the object identifier.

In yet another aspect, an object memory fabric is disclosed, comprising: a plurality of object memory modules, each object memory module comprising a single pluggable hardware module and further comprising an object store storing one or more memory objects, memory object metadata, and a memory module object directory, wherein: each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks; and the memory module object directory indexes all memory objects and/or portions of memory objects within the object memory module; and a hierarchy of object routers communicatively coupling the plurality of object memory modules, wherein: each object router of the hierarchy of object routers maintains an object cache state for at least one memory object and/or portion of memory objects contained in an object memory module under the object router along a descent line in the hierarchy originating from the object router; and based at least in part on the object cache state, the hierarchy of object routers is adapted to appear collectively as a single object directory communicatively coupled to all object memory modules, and to process requests based at least in part on the object cache state.

In yet another aspect, a hardware-based processing node is disclosed, comprising: an object memory module comprising a single pluggable hardware module, and further comprising an object store storing one or more memory objects and memory object metadata, wherein each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks; and an object router communicatively coupled to the object memory module, wherein the object router maintains an object cache state for at least one memory object and/or a portion of memory objects contained in the object memory module under the object router along a descent line in a hierarchy originating from the object router; the object router processes one or more requests based at least in part on the object cache state.

In yet another aspect, a method of storing and managing one or more memory objects in an object memory fabric is disclosed, the method comprising: storing one or more memory objects and memory object metadata in an object store of an object memory module, the object memory module comprising a single pluggable hardware module, wherein each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks; maintaining, by an object router communicatively coupled to the object memory module, an object cache state for at least one memory object and/or a portion of a memory object in the object memory module, wherein the object memory module follows a descent line under the object router from a hierarchy of the object router; and processing, by the object router, one or more requests based at least in part on the object cache state.

Drawings

Fig. 1 is a block diagram illustrating an example of separate data storage, memory and processing within a prior art commodity server and network element.

FIG. 2 is a block diagram illustrating components of an exemplary distributed system in which various embodiments of the invention may be implemented.

FIG. 3 is a block diagram illustrating an exemplary computer system upon which embodiments of the invention may be implemented.

Fig. 4 is a block diagram illustrating an exemplary unlimited object memory fabric (object memory fabric) architecture according to one embodiment of the invention.

FIG. 5 is a block diagram illustrating an exemplary object store structure object store in accordance with one embodiment of the present invention.

FIG. 6 is a block diagram illustrating exemplary object store dynamic and physical organization according to one embodiment of the invention.

FIG. 7 is a block diagram illustrating aspects of an object store structure hierarchy of an object store that localizes a working set and allows for nearly infinite scalability according to one embodiment of the invention.

FIG. 8 is a block diagram illustrating aspects of an example relationship between object address space, virtual addresses, and physical addresses, according to one embodiment of the invention.

FIG. 9 is a block diagram illustrating aspects of an example relationship between object size and object address space pointers, according to one embodiment of the invention.

FIG. 10 is a block diagram illustrating aspects of an example object store structure distributed object store and index structure, according to one embodiment of the invention.

FIG. 11 illustrates aspects of an object memory hit situation that is performed entirely within an object memory, according to one embodiment of the invention.

FIG. 12 illustrates aspects of object store misses and the distributed nature of object stores and object indexes, according to one embodiment of the invention.

FIG. 13 is a block diagram illustrating aspects of an example of leaf-level object store in view of an object store structure distributed object store and index structure, according to one embodiment of the invention.

FIG. 14 is a block diagram illustrating aspects of an example of an object memory fabric router object index structure, according to one embodiment of the invention.

Fig. 15A and 15B are block diagrams illustrating aspects of an example index tree structure including a node index tree structure and a leaf index tree, according to one embodiment of the invention.

FIG. 16 is a block diagram illustrating aspects of an example physical memory organization according to one embodiment of the invention.

FIG. 17A is a block diagram illustrating aspects of example object addressing, according to one embodiment of the invention.

FIG. 17B is a block diagram illustrating aspects of example object memory structure pointers and block addressing, according to one embodiment of the invention.

FIG. 18 is a block diagram illustrating aspects of example object metadata in accordance with one embodiment of the invention.

FIG. 19 is a block diagram illustrating aspects of an example micro-thread model, according to one embodiment of the invention.

FIG. 20 is a block diagram illustrating aspects of an example relationship of code, frames, and objects, according to one embodiment of the invention.

FIG. 21 is a block diagram illustrating an aspect of an example of micro-thread concurrency, according to one embodiment of the invention.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments of the invention. It will be apparent, however, to one skilled in the art that embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

The following description merely provides exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It being understood that various changes may be made in the function and arrangement of elements without departing from the scope of the invention as set forth in the appended claims.

In the following description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

In addition, it is noted that the various embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. Further, the order of operations may be rearranged. The process terminates after its operation is completed, but may have additional steps not included in the figure. The processes may correspond to methods, functions, procedures, subroutines, and the like. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or the main function.

The term "machine-readable medium" includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing or carrying instruction(s) and/or data. Code segments or machine-executable instructions may represent processes, functions, subroutines, procedures, routines, subroutines, modules, software packages, classes or instructions, data structures, or any combination of program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc. For clarity, various other terms used herein are now defined.

Virtual memory is a memory management technique that provides each software process with the illusion that memory is as large as the virtual address space. The operating system, in combination with varying degrees of hardware, manages physical memory as a cache of virtual address space, which is located in secondary storage and accessible through input/output instructions. Virtual memory is separate from, but can interact with, the file system.

Single level storage is an extension of virtual memory in which there are no files, only persistent objects or segments that are mapped to the address space of a process using virtual memory technology. The entire bank of the computing system is considered the segment and the addresses within the segment. Thus, at least three separate address spaces are managed by software, namely physical memory addresses/nodes, virtual addresses/processes, and auxiliary bank addresses/disks.

The object bank refers to an organization of units (referred to as objects) of the bank. Each object includes a container that includes three things: actual data; extensible metadata; and a globally unique identifier, referred to herein as an object address. Metadata of an object is used to define context information about the data, and how the data (including relationships with other objects) is used and managed.

The object address space is managed by software on storage, nodes, and networks to find objects without knowing their physical locations. The object store is separate from the virtual memory and single level storage, but can interoperate through software.

The block memory bank is made up of uniformly sized blocks of data, with addresses based on physical location, and no metadata.

The network address is a physical address of a node associated with a physical location within the IP network.

A node or processing node is a physical unit of computation depicted by a shared physical memory addressed by any processor within the node.

The object store is the object store that is directly accessed as memory by the processor memory reference instructions and does not require implicit or explicit software or input/output instructions. Object capabilities are provided directly within the object memory for processing by memory reference instructions.

The object memory fabric connects the object memory modules and nodes into a single object memory, in which case any object is local to any object memory module by direct management of object data, metadata, and object addresses in hardware.

The object router routes the object or portion of the object in the object memory fabric based on the object address. This is in contrast to conventional routers which forward data packets to the appropriate portion of the network based on network addresses.

Embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium. The processor(s) may perform the necessary tasks.

Embodiments of the present invention provide systems and methods for managing processing, memory, storage, networking, and cloud computing to significantly improve the efficiency and performance of processing nodes. The embodiments described herein may be implemented in a collection of hardware components that substantially change the manner in which processes, memories and banks, networks and cloud computing are managed by breaking the artificial distinction between processes, memories, banks and networks in commodity solutions today to significantly improve the efficiency and performance of commodity hardware. For example, the hardware elements may include a standard format memory module, such as a (DIMM), and a set of one or more object routers. The memory module may be added to commodity or "off-the-shelf" hardware such as a server node and act as a big data accelerator within that node. The object router may be used to interconnect two or more servers or other nodes adapted with memory modules and to help manage processing, memory, and storage across these different servers. Nodes may be physically very close or very far apart. These hardware components may be used together with a commodity server or other type of computing node in any combination to implement the embodiments described herein.

According to one embodiment, such hardware components may implement object-based memory that manages objects within memory in the memory layer rather than in the application layer. That is, the objects and associated attributes are implemented and managed locally in memory, allowing the object memory to provide increased functionality without any software, and increased performance by dynamically managing object properties (including, but not limited to, persistence, location, and processing). Object properties can also be propagated to higher application levels.

Such hardware components may also be implemented and managed within the object to eliminate distinction between memory (temporary) and storage (permanent). These components can eliminate the distinction between local and remote memory by transparently managing the location of objects (or portions of objects), so that all objects appear to be local to all nodes at the same time. These components may also eliminate distinction between processes and memory by way of objects to place the processes within the memory itself.

According to one embodiment, such hardware components may eliminate the typical size limitations of the memory space of the commodity server imposed by the address size. Instead, physical addressing can be managed within the memory object itself, and in turn, the object can be accessed and managed through the object name space.

Embodiments described herein may provide transparent and dynamic performance acceleration, particularly for large data or other memory-intensive applications, by reducing or eliminating overhead (overhead) typically associated with memory management, bank management, networking, and data directories. In contrast, management of memory objects at the memory level can significantly shorten the path between memory and memory banks, and between memory and processing, thereby eliminating the associated overhead between each. Various additional details of embodiments of the present invention will be described below with reference to the accompanying drawings.

FIG. 2 is a block diagram of components of an exemplary distributed system in which various embodiments of the present invention may be implemented. In the illustrated embodiment, the distributed system 200 includes one or more client computing devices 202, 204, 206, and 208 configured to execute or operate client applications, such as Web browsers, dedicated clients, and the like, on one or more networks 210. The server 212 may be communicatively coupled with the remote client computing devices 202, 204, 206, and 208 via the network 210.

In various embodiments, server 212 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided to users of client computing devices 202, 204, 206, and/or 208 as Web-based or cloud services or software as a service (SaaS) modes. A user operating client computing devices 202, 204, 206, and/or 208 may in turn interact with server 212 using one or more client applications to take advantage of the services provided by these components. For clarity, it should be noted that server 212 and databases 214, 216 may correspond to server 105 described above with reference to fig. 1. Network 210 may be part of or an extension to physical network 115. It should also be appreciated that there may be any number of client computing devices 202, 204, 206, 208 and servers 212, each having one or more databases 214, 216.

In the configuration depicted in the figure, software components 218, 220, and 222 of system 200 are shown as being implemented on server 212. In other embodiments, one or more components of system 200 and/or services provided by those components may also be implemented by one or more of client computing devices 202, 204, 206, and/or 208. A user operating a client computing device may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be appreciated that a variety of different system configurations other than distributed system 200 are possible. Thus, the embodiment shown in the figures is one example of a distributed system for implementing embodiments of the system, and is not intended to be limiting.

The client computing devices 202, 204, 206, and/or 208 may be portable handheld devices (e.g.,cellular phone, & lt & gt>Computing tablet, personal Digital Assistant (PDA)) or wearable device (e.g., google +.>Head mounted display) operating for example Microsoft Windows +.>And/or various mobile operating systems, such as iOS, windows Phone, android, blackBerry, palm OS, etc., and may be accessed by the internet, email, short Message Service (SMS), or + >Or other allowed communication protocol enablement. The client computing device may be a general purpose deviceWith personal computers, including personal computers and/or laptop computers, for example, running various versions of MicrosoftAppleAnd/or a Linux operating system. The client computing device may be a workstation computer running various commercially available +.>Or any of the UNIX-like operating systems, including but not limited to various GNU/Linux operating systems, such as Google Chrome OS. Alternatively or additionally, the client computing devices 202, 204, 206, and 208 may be any other electronic device, such as a lightweight, thin client computer, an internet-enabled gaming system (e.g., microsoft Xbox game console, with or without +.>Gesture input device), and/or a personal messaging device capable of communicating over network(s) 210.

Although the exemplary distributed system 200 is shown with four client computing devices, any number of client computing devices may be supported. Other devices (e.g., devices with sensors, etc.) may interact with the server 212.

Network(s) 210 in distributed system 200 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially available protocols, including, but not limited to, TCP/IP (transmission control protocol/internet protocol), SNA (system network architecture), IPX (internet packet exchange), appleTalk, and the like. For example only, the network(s) 210 may be a Local Area Network (LAN), such as an ethernet, token ring, and/or the like based LAN. Network(s) 210 may be wide area networks and the internet. Which may include virtual networks, including but not limited to Virtual Private Networks (VPN), intranets External networks, public Switched Telephone Networks (PSTN), infrared networks, wireless networks (e.g., in any Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol suite),And/or any other network operating under a wireless protocol); and/or any combination of these and/or other networks. The elements of these networks may be any distance, i.e. may be remotely or co-located. A Software Defined Network (SDN) may be implemented by a combination of non-intelligent (dumb) routers and software running on servers.

The server 212 may be composed of: one or more general purpose computers, special purpose server computers (e.g., including a Personal Computer (PC) server),Servers, medium servers, mainframe computers, rack-mounted servers, etc.), a server farm, a cluster of servers, or any other suitable arrangement and/or combination. In various embodiments, the server 212 may be adapted to run one or more of the services or software applications described in the foregoing disclosure. For example, the server 212 may correspond to a server that performs the above-described processing according to an embodiment of the present disclosure.

The operating system that server 212 may run includes any of the above, as well as any commercially available server operating system. The server 212 may also run any of a variety of additional server applications and/or middle tier applications, including a hypertext transfer protocol (HTTP) server, a File Transfer Protocol (FTP) server, a Common Gateway Interface (CGI) server, Servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle, microsoft, sybase, international Business Machines (IBM), and the like.

In some implementations, the server 212 can include one or more applications toData feeds and/or event updates received from client computing devices 202, 204, 206, and 208 are analyzed and integrated. As an example, the data feeds and/or event updates may include, but are not limited toFeed, & lt & gt>Updates, or real-time updates received from one or more third party information sources and continuous data streams, which may include real-time events related to sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like. Server 212 may also include one or more applications to display data feeds and/or real-time events via one or more display devices of client computing devices 202, 204, 206, and 208.

The distributed system 200 may also include one or more databases 214 and 216. Databases 214 and 216 may reside in various locations. As an example, one or more of databases 214 and 216 may reside on a non-transitory storage medium that is local to server 212 (and/or resides in server 212). Alternatively, databases 214 and 216 may be remote from server 212 and in communication with server 212 via a network-based or dedicated connection. In one set of embodiments, databases 214 and 216 may reside in a Storage Area Network (SAN). Similarly, any necessary files for performing the functions attributed to server 212 may be stored locally at server 212 and/or remotely, as desired. In one set of embodiments, databases 214 and 216 may include a relational database adapted to store, update, or retrieve data in response to commands (e.g., mySQL-formatted commands). Additionally or alternatively, server 212 may provide and support large data processing of unstructured data, including but not limited to Hadoop processing, noSQL databases, graphics databases, and the like. In yet another embodiment, server 212 may execute big data applications of non-database types, including but not limited to machine learning.

FIG. 3 is a block diagram of an exemplary computer system in which embodiments of the invention may be implemented. The system 300 may be used to implement any of the computer systems described above. As shown, computer system 300 includes a processing unit 304 that communicates with a plurality of peripheral subsystems via a bus subsystem 302. These peripheral subsystems may include a processing acceleration unit 306, an I/O subsystem 308, a bank subsystem 318, and a communication subsystem 324. The storage subsystem 318 includes a tangible computer-readable storage medium 322 and system memory 310.

Bus subsystem 302 provides a mechanism for allowing the various components and subsystems of computer system 300 to communicate with each other as intended. Although bus subsystem 302 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 302 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Such architectures can include, for example, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, a Peripheral Component Interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured by the IEEE P1386.1 standard, or a PCI enhanced (PCIe) bus.

The processing unit 304, which may be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 300. One or more processors may be included in processing unit 304. These processors may include single-core or multi-core processors. In some embodiments, processing unit 304 may be implemented as one or more separate processing units 332 and/or 334, each including a single-core or multi-core processor therein. In other embodiments, processing unit 304 may also be implemented as a four-core processing unit formed by integrating two dual-core processors into a single chip.

In various embodiments, the processing unit 304 may execute various programs in response to program code, and may maintain multiple concurrently executing programs or processes. Some or all of the program code to be executed may reside at any given time in the processor(s) 304 and/or the memory bank subsystem 318. The processor(s) 304 may provide the various functions described above by suitable programming. The computer system 300 may additionally include a processing acceleration unit 306, which may include a Digital Signal Processor (DSP), a special-purpose processor, and/or the like.

The I/O subsystem 308 may include user interface input devices and user interface output devices. The user interface input device may include a keyboard, a pointing device such as a mouse or trackball, a touch pad or screen incorporated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, an audio input device with a voice command recognition system, a microphone, or other type of input device. The user interface input means may for example comprise motion sensing and/or gesture recognition means, such as MicrosoftMotion sensor allowing a user to control an input device through a natural user interface using gestures and spoken commands (e.g. Microsoft +.>360 game controller) and interact with the input device. The user interface input means may also comprise eye movement recognition means, e.g. Google +.>A blink detector that detects eye activity from a user (e.g., "blink" when taking a photograph and/or making a menu selection) and converts the eye activity into a visual signal to an input device (e.g., google>) Is input to the computer. Furthermore, the user interface input means may comprise voice recognition sensing means allowing the user to communicate with the voice recognition system (e.g.) >Navigator).

User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or sticks, game pads and graphics tablets, and audio/video devices such as speakers, digital cameras, digital video cameras, portable media players, web cameras, image scanners, fingerprint scanners, bar code readers, 3D scanners, 3D printers, laser rangefinders, and eye gaze tracking devices. Furthermore, the user interface input device may for example comprise a medical imaging input device, such as a computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound examination device. The user interface input means may also for example comprise audio input means such as MIDI keyboards, digital musical instruments, etc.

The user interface output device may include a display subsystem, an indicator light, or a non-visual display, such as an audio output device, or the like. The display subsystem may be a Cathode Ray Tube (CRT), a flat panel device (e.g., a flat panel device using a Liquid Crystal Display (LCD) or a plasma display), a projection device, a touch screen, etc. In general, the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 300 to a user or other computers. For example, the user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio/video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

Computer system 300 may include a bank subsystem 318 that includes software elements shown as currently located within system memory 310. The system memory 310 may store program instructions that may be loaded and executed on the processing unit 304, as well as data generated during the execution of such programs.

Depending on the configuration and type of computer system 300, system memory 310 may be volatile (e.g., random Access Memory (RAM)) and/or nonvolatile (e.g., memory storage mediumRead Only Memory (ROM), flash memory, etc.). RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated on and executed by processing unit 304. In some cases, system memory 310 may include one or more double data rate four-generation (DDR 4) Dual Inline Memory Modules (DIMMs). In some embodiments, system memory 310 may include a variety of different types of memory, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). In some embodiments, a basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 300, such as during start-up, may be stored in ROM. By way of example, and not limitation, system memory 310 also illustrates application programs 312, which may include client applications, web browsers, middle tier applications, relational database management systems (RDBMS), and the like, program data 314, and operating system 316. By way of example, operating system 316 may include various versions of Microsoft Windows AppleAnd/or Linux operating system, various commercially availableOr UNIX-like operating systems (including but not limited to GNU/Linux operating system, google +.>OS, etc.) and/or mobile operating systems, e.g., iOS,/s->Mobile phone and (E) the same>OS、10OS, ->The OS operating system.

The storage volume subsystem 318 may also provide a tangible computer readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that when executed by a processor provide the functionality described above may be stored in the memory bank subsystem 318. These software modules or instructions may be executed by the processing unit 304. The storage subsystem 318 may also provide a repository (repository) for storing data for use in accordance with the present invention.

The storage subsystem 300 may also include a computer-readable storage media reader 320, which may be further connected to a computer-readable storage medium 322. Together and optionally in conjunction with system memory 310, computer-readable storage medium 322 may comprehensively represent remote, local, fixed, and/or removable storage plus storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information.

Computer-readable storage media 322, which contain code, or portions of code, may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information. This may include tangible computer-readable storage media such as RAM, ROM, electrically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This may also include intangible computer readable media, such as digital signals, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by computing system 300.

As an example of this, the number of devices,the computer-readable storage medium 322 may include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, a removable, nonvolatile optical disk (e.g., CD ROM, DVD, and DVD A disk, or other optical medium) to read from or write to. The computer readable storage medium 322 may include, but is not limited to,>drives, flash memory cards, universal bus (USB) flash drives, secure Digital (SD) cards, DVD discs, digital video bands, and the like. The computer-readable storage medium 322 may also include a non-volatile memory based Solid State Drive (SSD), a flash memory based SSD, an enterprise flash drive, a solid state ROM, or the like; volatile memory-based SSDs, such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for computer system 300.

Communication subsystem 324 provides an interface with other computer systems and networks. Communication subsystem 324 serves as an interface for computer system 300 to receive data from and send data to other systems. For example, communication subsystem 324 may allow computer system 300 to connect to one or more devices via the internet. In some embodiments, the communication subsystem 324 may include Radio Frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data networking technology such as 3G, 4G, or enhanced data rates for global evolution (EDGE), wiFi (IEEE 802.11 family standards or other mobile communication technologies), or any combination thereof), global Positioning System (GPS) receiver components, and/or other components. In some embodiments, communication subsystem 324 may provide a wired network connection (e.g., ethernet) in lieu of, or in addition to, a wireless interface. In some cases, communication subsystem 324 may be implemented in whole or in part as one or more PCIe cards.

In some embodiments, the communication subsystem 324 may also receive input communications in the form of structured and/or unstructured data feeds 326, event streams 328, event updates 330, and the like, on behalf of one or more users who may use the computer system 300.

By way of example, the communication subsystem 324 may be configured to communicate with other communication services from a social network and/or other communication services (e.g.,feed, & lt & gt>Updates, web feeds such as Rich Site Summary (RSS) feeds), receives data feeds 326 in real-time, and/or receives real-time updates from one or more third-party information sources.

In addition, the communication subsystem 324 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 328 of real-time events and/or event updates 330, which may be continuous or unbounded in nature, without explicit ending. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), click stream analysis tools, automotive traffic monitoring, and the like.

The communication subsystem 324 may also be configured to output structured and/or unstructured data feeds 326, event streams 328, event updates 330, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 300.

The computer system 300 may be one of various types, including a hand-held portable device (e.g.,cellular phone, & lt & gt>Computing tablet, PDA), wearable device (e.g., google->Head mounted display), a PC, a workstation, a mainframe, a kiosk (kiosk), a server rack, or any other data processing system.

Due to the ever-changing nature of computers and networks, the description of computer system 300 depicted in the drawings is intended only as a specific example. Many other configurations with more or fewer components than the system shown in the figures are possible. For example, custom hardware may be used and/or specific elements may be implemented in hardware, firmware, software (including applets), or combinations. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and/or methods of implementing the various embodiments.

As introduced above, embodiments of the present invention provide systems and methods for managing processing, memory, storage, network, and cloud computing to significantly improve the efficiency and performance of processing nodes, such as any of the servers or other computers or computing devices described above. The embodiments described herein may be implemented as a collection of hardware components that substantially change the manner in which processes, memory and storage, network and cloud computing are managed by breaking the artificial distinction between processes, memory, storage, network and cloud in commodity solutions today to significantly improve the performance of commodity hardware. For example, the hardware elements may include standard format memory modules, such as dual in-line memory modules (DIMMs), which may be added to any of the computer systems described above. For example, a memory module may be added to commodity or "off-the-shelf" hardware such as a server node and act as a big data accelerator within that node. The component may also include one or more object routers. The object router may, for example, comprise a PCIe card that is added to the server node along with the memory module and one or more external object routers (e.g., rack-mount routers). An object router may be used to interconnect two or more servers or other nodes adapted to memory modules and facilitate management of processes, memory, and storage volumes on these different servers, and may forward objects or portions of objects based on object addresses and participate in operations in an object memory structure. These hardware components may be used in any combination with commodity servers or other types of computing nodes to implement an object memory fabric architecture.

FIG. 4 is a block diagram illustrating an exemplary object memory architecture according to one embodiment of the invention. As shown herein, architecture 400 includes an object memory structure 405 supporting any number of applications 410a-g. As will be described in greater detail below, the object memory fabric 405 may include any number of processing nodes, such as one or more servers, having installed one or more memory modules described herein. The nodes may be interconnected by one or more internal and/or external object routers as described herein. Although described as including one or more servers, it should be noted that the processing nodes of the object store structure 405 can include any number of various different computers and/or computing devices adapted to operate within the object store structure 405 as described herein.

According to one embodiment, the object memory fabric 405 provides object-based memory that manages memory objects within the memory of the nodes of the object memory fabric 405 in the memory layer rather than in the application layer. That is, objects and associated attributes may be implemented and managed locally in nodes of object store structure 405 to provide increased functionality without any software and to increase efficiency and performance by dynamically managing object properties, including, but not limited to, persistence, location, and processing. Object properties may also be propagated to applications 410a-g. The memory objects of the object memory structure 405 may be used to eliminate the typical size constraints imposed on the memory space of a commodity server or other node by the address size. Instead, physical addressing may be managed within the memory object itself, and the object may in turn be accessed and managed through the object namespace. The memory objects of object memory structure 405 may also be implemented and managed within the object to eliminate distinction between memory (temporary) and memory banks (persistent). The object store structure 405 can also eliminate the distinction between local and remote stores by transparently managing the location of objects (or portions of objects) so that all objects appear to be local to all nodes at the same time. The memory object may also eliminate distinction between processing and memory by the way the object is placed in the memory itself. In other words, embodiments of the present invention provide a single level memory that incorporates computation and storage and both storage and computation, directly and thereby eliminating the multi-level software overhead of communicating on these levels as well as the human overhead of moving the data to be processed.

In these ways, by reducing or eliminating the overhead typically associated with memory management, bank management, networks, data directories, and data buffers on the system and application software layers, embodiments of the object memory fabric 405 and its components described herein can provide transparent and dynamic performance acceleration, particularly for large data or other memory-intensive applications. In contrast, management of memory objects at the memory level can significantly shorten the path between memory banks and memory and between memory and processing, thereby eliminating the associated overhead between each of them.

Embodiments provide a consistent, hardware-based, unlimited memory managed as a memory object, with accelerated performance in memory, across all nodes, and extensible across all nodes. This allows transparent dynamic performance acceleration based on objects and ending applications. Using architecture according to embodiments of the present invention, applications and system software can be considered as simple and as a single standard server, but additionally allow memory structure objects to capture heuristics. Embodiments provide multi-dimensional acceleration performance, including local acceleration. According to one embodiment, object memory fabric metadata associated with a memory object may include a trigger that enables the object memory fabric architecture to be localized and move data to flash DRAM memory prior to use. A trigger may be a basic generalization that enables a memory system to perform any function based on a memory access. Various embodiments may also include an instruction set that may provide a unique instruction model of the object memory structure based on triggers defined in metadata associated with each memory object that supports core operations and optimizations and allows for more efficient execution of memory-intensive portions of an application in a highly parallel manner within an IMF.

Embodiments may also reduce software path length by replacing a small number of memory references with complex applications, memory banks, and network stacks. This can be achieved when the memory and the memory banks are directly addressable as memory under an embodiment of the invention. Embodiments may additionally provide acceleration performance for high level memory operations. For many cases, embodiments of the object memory fabric architecture may eliminate the need to move data to the processor and back to memory (which is very inefficient for current modern processors with three or more levels of cache).

FIG. 5 is a block diagram illustrating an exemplary memory structure object memory in accordance with one embodiment of the invention. More specifically, this example shows how an application view of a memory structure object memory may be organized. Memory structure object address space 500 may be a 128-bit linear address space, in which case the object ID corresponds to the beginning of an addressable object. Object 510 may be from 2 ¹² To 2 ⁶⁴ Variable size of bytes. Because the object memory banks are allocated on a per block basis, the address space 500 may be utilized sparsely within or across objects efficiently. The size of the object space 500 must be large enough so that garbage collection is not required and that disjoint systems can be easily combined.

The object metadata 505 associated with each object 510 may be transparent to the object address space 500 and may utilize the object memory structure to manage the objects and blocks within the objects and may be accessed by the applications 515a-g with appropriate rights through an Application Program Interface (API) of the object memory structure. The API provides the functionality for the application to set and maintain the object memory structure, for example by using a library of modified Linux libc functions. Applications such as SQL databases or graphics databases can utilize APIs to create memory objects and provide and/or extend object metadata to allow an object memory structure to better manage objects with little additional effort. Object metadata 505 may include object methods that enable performance optimization through dynamic object-based processing, distribution, and parallelization. The metadata may enable each object to have a definable security policy and access the encapsulation within the object.

According to embodiments of the invention, applications 515a-g may now access a single object (e.g., app0 515 a) capturing their work and/or persistence data, or multiple objects for better granularity (e.g., app1 515 b). Applications may also share objects. The object store 500 according to these embodiments may physically implement such a powerful simple application view through a combination of physical organization (which will be described in more detail below with reference to fig. 6) and object store dynamics. In general, object store 500 can be organized as a distributed hierarchy that creates hierarchical neighbors for object stores and applications 515 a-g. The object store dynamically interacts and utilizes hierarchical organization to dynamically create local variables (locals) of the object and applications (object methods) that operate on the object. Since object methods can be associated with memory objects, the object methods naturally achieve the increased parallelism guaranteed by the object size when the objects migrate and replicate across the memory structure. The hierarchy in conjunction with object dynamics may further create a neighborhood of the neighborhood based on the size and dynamics of the object method.

FIG. 6 is a block diagram illustrating exemplary object store dynamic and physical organization according to one embodiment of the invention. As shown in this example, the above-described object memory fabric 600 may include any number of processing nodes 605 and 610 communicatively coupled via one or more external object routers 615. Each of nodes 605 and 610 may also include an internal object router 620 and one or more memory modules. Each memory module 625 may include node object memory 635 supporting any number of applications 515 a-g. In general, the memory module 625, the node object router 620, and the inter-node object router 615 may share common functions and indexes thereof with respect to the object store 635. In other words, the underlying design object may be reused in all three, providing a generic design of hardware suitable for any of a variety of different form factors and types, in addition to those described by way of example.

More specifically, a node may include a single node object router 620 and one or more memory modules 625 and 630. According to one embodiment, node 605 may comprise a commodity or "off-the-shelf" server, memory module 625 may comprise a standard format memory card, such as a dual in-line memory module (DIMM) card, and node object router 620 may similarly comprise a standard format card, such as a peripheral component interconnect express (PCIe) card. Node object router 620 may implement object indexes of objects/blocks held within object memory(s) 635 of memory modules 625 and 630 within the same node 605. Each of the memory modules 625 and 630 may hold actual objects and blocks within the object, corresponding object metadata, and an object index that overlays the objects currently stored locally in that memory module. Each of the memory modules 625 and 630 may independently manage DRAM memory (fast and relatively expensive) and flash memory (less fast but much cheaper) in a manner such that the processor (not shown) of the node 605 deems there to be a flash amount of flash DRAM. The memory modules 625 and 630 and the node object router 620 may manage free memory banks by free memory bank indexes implemented in the same manner as other indexes. The memory modules 625 and 630 may be directly accessed by the processor caches and processor memory reference instructions over a standard DDR memory bus. In this way, the memory objects of memory modules 625 and 630 may be accessed using only conventional memory reference instructions, without the need for implicit or explicit input/output (I/O) instructions.

The objects within the object store 635 of each node 625 may be created and maintained through an object store structure API (not shown). Node object router 620 may communicate with the API through a modified object memory fabric version of the libc function library and an object memory fabric driver (not shown). Node object router 620 may then update the local object index as needed, send commands towards the root (i.e., towards inter-node object router 615), and communicate with the appropriate memory module 625 or 630 to complete the API commands locally. The memory module 625 or 630 may communicate the management request back to the node object router 620, which may process them appropriately.

According to one embodiment, the internal architecture of node object router 620 may be very similar to memory module 625, with differences related to routing functions such as managing node memory object indexes and routing appropriate packets to and from memory modules 625 and 630 and inter-node object router 615. That is, node object router 620 may have additional routing functionality, but does not require actual storage of memory objects.

Inter-node object router 615 may be considered similar to an IP router. However, the first difference is the addressing model used. The IP router uses a fixed static address at each node and routes to a fixed physical node based on the destination IP address. However, inter-node object router 615 of object memory fabric 600 utilizes a memory fabric Object Address (OA), which specifies the object and a particular block of the object. Objects and blocks may reside dynamically at any node. Inter-node object router 615 may route OA packets based on the dynamic position(s) of objects and blocks and dynamically track object/block positions in real-time. A second difference is that the object router may implement an object memory fabric distributed protocol that provides dynamic properties of object/block location and object functionality, including, for example, but not limited to, triggers. Inter-node object router 615 may be implemented as an enlarged version of node object router 620 with increased object index storage capacity, processing rate, and overall routing bandwidth. In addition, the inter-node object router 615 may be connected to multiple node object routers and/or multiple other inter-node object routers, rather than to a single PCIe or other bus or lane to connect to a memory module. According to one embodiment, node object router 620 may communicate with memory modules 625 and 630 through direct memory access over PCIe and a memory bus (not shown) of node 605. The node object routers of the different nodes 605 and 610 may in turn be connected to one or more inter-node object routers 615 via a high-speed network (not shown), such as a 25/100GE fiber using several layers of gigabit ethernet protocol or object memory fabric protocol transported over standard IP tunnels. Multiple inter-node object routers may be connected to the same network.

In operation, the memory structure object store may implement its brute force simple application view described above with reference to fig. 4 and 5 through a combination of physical organization and object store dynamics. According to one embodiment and as described with reference to FIG. 5, the memory structure object store may be organized as a distributed hierarchy that forms a hierarchical neighborhood of object stores and applications 515 a-g. The node object router may keep track of which object or portion of an object is local to the neighborhood. The actual object store may be located on nodes 605 or 610 near the applications 515a-g and the memory fabric object methods.

Also as introduced above, object store dynamics can interact and utilize hierarchical organization to dynamically create local variables of objects and applications operating on objects (object methods). Since object methods can be associated with objects, the object methods naturally achieve the increased parallelism guaranteed by the object size when the objects migrate and replicate on the nodes. The object hierarchy in conjunction with object dynamics may in turn create a neighborhood of the neighborhood based on the size of the object method and the dynamics.

For example, app0 515a spans multiple memory dies 625 and 630 within a single level of object memory fabric neighborhood (in this case node 605). Object movement may stay within the neighborhood and its node object router 620 without any other communication links or routers. The self-organizing nature of the neighborhood defined along the hierarchy provides efficiency from a performance and minimum bandwidth perspective. In another example, app1 (Al) 515b may have the same characteristics but in a different neighborhood, i.e., in node 610. App2 (A2) 515c may be a parallel application across two levels of hierarchical neighborhood (i.e., nodes 605 and 610). Interactions may be self-integrating in the corresponding neighborhood.

As described above, certain embodiments may include data types and metadata schemas, and certain embodiments may also include data types and metadata schemas that facilitate the various advantages of the present invention. Regarding architecture, the following description discloses the following aspects: an object memory structure address space; an object address space in which the object memory structure is coherent; object store structure distributed object store and index; an object memory structure index; an object memory structure object; and an extended instruction execution model. Various embodiments may include any one or combination of these aspects.

FIG. 7 is a block diagram illustrating aspects of an object store structure hierarchy of an object store that localizes a working set and allows for nearly infinite scalability according to one embodiment of the invention. As disclosed herein, certain embodiments may include core organization and data types that allow an object memory fabric to dynamically operate to provide an object memory application view. The core organization and data types contribute to the fractal-like nature of the system, which allows the system to behave the same in a scale-independent manner. In the illustrated example, the object memory fabric 700 disclosed herein can include any number of processing nodes 705 and 710 communicatively coupled to higher levels via one or more external object routers, such as object router 715, which can in turn be coupled to one or more higher level object routers.

In particular, the system may be a fat tree built by nodes (from leaf nodes to root node (s)). According to some embodiments, each node may simply understand whether its scope contains objects, and based on whether requests/responses are routed to the root or leaf. Bringing the nodes together enables the system to dynamically extend to any capacity without affecting the operation or point of view of any node. In some embodiments, the leaf nodes may be DIMMs built from standard memory chips, plus an object memory structure 700 implemented within an FPGA. In some embodiments, a standard memory chip may have an embedded object memory structure 700. In various embodiments, implementations may have a remote node, such as a mobile phone, drone, automobile, internet of things component, and/or the like.

To facilitate various advantageous properties of the object memory fabric 700, some embodiments may employ a coherent object memory fabric address space. Table 1 below identifies non-limiting examples of various aspects of an address space according to certain embodiments of the present disclosure. According to some embodiments, all nodes connected to a single object store structure 700, either local or distributed, may be considered part of a single system environment. As shown in table 1, object memory fabric 700 may provide a coherent object address space. In some embodiments, a 128-bit object address space may be provided. However, other embodiments are possible. The large object address space has several reasons, including the following. The object address space addresses directly uniquely and manages all memories, banks, on all nodes within the object memory fabric system and provides unique addresses for conventional banks outside the object memory fabric system. The object address space may allow addresses to be used once without garbage collection, which is a major efficiency. The object address space may allow distinguishing between allocation address space and allocation banks. In other words, the object address space can be sparsely used as an effective technique with simplicity, performance, and flexibility.

As further shown in Table 1, object store structure 700 may directly support the virtual address space and the physical address space of each process. By some embodiments, the virtual address space and the physical address space of each process may be compatible with the x86-64 architecture. In some embodiments, the span of a single virtual address space may be in a single instance of the Linux OS and may generally coincide with a single node. The object memory fabric 700 may allow the same virtual address space to span more than a single node. The physical address space may be actual physical memory addressing (e.g., within the x86-64 nodes in some embodiments).

Fig. 8 is a block diagram illustrating an example relationship 800 between an object address space 805, a virtual address 810, and a physical address 815, according to some embodiments of the present disclosure. For object address space 805, the size of individual objects may vary within a range. By way of example and not limitation, the size of a single object may range from 2 megabytes (2 ²¹ ) To 16PB (2) ⁶⁴ ). Other ranges are possible. In some embodiments, in object memory fabric 700, object address space 805 may be allocated on an object granularity basis. In some embodiments, the banks may be allocated on a 4 kbyte block basis (e.g., blocks 806, 807). Thus, in some embodiments, the object address space blocks 806, 807 may correspond to a 4 kbyte page size within the x86-64 architecture. When creating the object address space 805, only the address space and object metadata can exist. When a bank is allocated on a per block basis, there may be data stored in the corresponding block of the object. The block banks may be allocated in a sparse or non-sparse manner and pre-allocated and/or allocated on demand. For example, in some embodiments, software may use objects as hash functions and allocate physical memory banks only for valid hashes.

Referring to the example of FIG. 8, within nodes 820,825, which may be conventional servers in some embodiments, physical pages corresponding to physical address 815 may be allocated on a dynamic basis corresponding to virtual address 810. Since the object memory fabric 700 actually provides physical memory within the nodes 820,825 through the object memory fabric DIMM, when virtual address segments 811, 812, 813, 814 are allocated, an object address space 805 object corresponding to a particular segment 811, 812, 813, 814 may also be created. This causes the same or different virtual addresses 810 on nodes 820,825 to seek or access the same object. The actual physical address 815 at which the blocks/pages within the object are located within the nodes 820,825 may vary over time within or on the nodes 820,825, transparent to the application software.

Some embodiments of object memory fabric 700 may provide key advantages: embodiments of object memory fabric 700 may provide integrated addressing, objects with transparent invariant pointers (no rotation is required), and methods of accessing large address spaces across nodes-some embodiments are compatible with x84-64, linux, and applications. Typically, a system has many different addresses (e.g., for memory addresses with separate address spaces, sectors, cylinders, physical disks, database systems, file systems, etc.), which requires significant software overhead to translate, buffer, and move objects and blocks between the different address layers. Addressing objects, and blocks within objects, using integrated addressing, and using object namespaces eliminates the software layer by enabling a single level of addressing that is unchanged across all nodes/systems. With a sufficiently large address space, one address system is not unchanged with a particular database application and all of these systems working together.

Thus, a node may include a memory module that may store and manage one or more memory objects, wherein physical addresses of memory and banks are managed with each of the one or more memory objects based at least in part on an object address space allocated on a per object basis using a single level object addressing scheme. The node may be configured to operatively couple to one or more additional nodes using the object addressing scheme to operate as a set of nodes of an object memory fabric, wherein the set of nodes are operative to make all memory objects of the set of nodes accessible based at least in part on the object addressing scheme, the object addressing scheme defining unchanged object addresses for the one or more memory objects, the object addresses being variable relative to physical memory storage locations and storage locations of the one or more memory objects within the memory module and unchanged across all modules interfacing with the object memory fabric. Accordingly, the object address is unchanged within a module and across all modules that the object memory fabric meets, whether or not the object is in a single server. Even though the object may be stored on any or all of the modules, the object address remains unchanged regardless of the physical memory location in which the object is currently or to be stored. Details of some embodiments are provided below that may provide such advantages through object address space and object address space pointers.

Some embodiments of object memory fabric 700 may support a variety of pointer formats. Fig. 9 is a block diagram illustrating an example relationship 900 between an object size 905 and an object address space pointer 910, according to some embodiments of the present disclosure. Table 1 table 2 below identifies non-limiting examples of aspects of object address space pointer 910 according to certain embodiments of the present disclosure. As shown in table 1 and table 2, some example embodiments may support three pointer formats. The object address space format may be a 128-bit format local to the object memory structure and may provide a single pointer with full addressability for any object and offset within the object. The object memory fabric 700 may support two additional formats, e.g., a 64-bit format, to allow for direct compatibility with x86-64 virtual memory and virtual addresses. Once the relationship between the object memory fabric object and the virtual address segment is established through the object memory fabric API (which in some embodiments may be handled transparently to the application in the Linux libc function library), the standard x86 Linux program may directly reference the data within the object (x 86 segment), efficiently and transparently utilizing the x86-64 addressing mechanism.

Table 1 table 2 and table 3 below identify object address spaces in accordance with certain embodiments of the present disclosureNon-limiting examples of aspects of pointer relative to object size. Embodiments of the object address space may support multiple segment sizes, e.g., from 2 as shown in Table 1, table 2 and Table 3 below ²¹ To 2 ⁶⁴ Is equal to the six segment sizes of (a). The object size corresponds to the x86-64 virtual memory segment and the large page size. The object may start from a modulo 0 object size boundary. The object address space pointer 910 may be broken down into the ObjStart and ObjOffset fields, the size of which depends on the object size, as shown in the examples below. The ObjStart field corresponds to the object address space start of the object and also corresponds to the ObjectID. The ObjOffset is an unsigned value in the range from zero to (ObjectSize-1), specifying an offset within the object. The object metadata may specify the object size and object memory fabric interpretation of the object address space pointer 910. Objects of arbitrary size and sparsity may be specified by simply allocating a bank to a block of interest within the object.

Due to the nature of most applications and the nature of the objects of object memory fabric 700, most addressing may be relative to the objects. In some embodiments, all object memory fabric address pointer formats may be stored and loaded locally by the processor. In some embodiments, object-relative and object-virtual addresses may directly use the x86-64 addressing mode. The object virtual address pointer may be or include a process virtual address that works within the x86-64 segment and corresponding object memory fabric object. Object memory architecture the object address space can be calculated by using the object virtual address as the object offset. The object relative pointer may be or include an offset to the x86-64 virtual address segment so that the reference plus index addressing mode works perfectly. Object memory structure the object address space can be calculated by using the object relative as the object offset. Table 3 below identifies a non-limiting example of details of generating a 128-bit object address space from an object virtual address or object relative pointer as a function of object size, according to some embodiments of the present disclosure.

As disclosed herein, certain embodiments may include an object store structure distributed object store and index. Using distributed indexing, individual nodes can index local objects and blocks of objects on a per object basis. Some embodiments of object memory architecture distributed object memory and indexing may be based at least in part on the cross-point concept of cellular automata and fat trees. Existing distributed hardware and software systems with real-time dynamic indexing use two methods: a centralized index or a distributed single concept index. Embodiments of the object memory architecture may use a new approach to overlay independent local index functions on top of fat tree hierarchical networks.

Fig. 10 is a block diagram illustrating an example object store structure distributed object store and index structure 1000 in accordance with some embodiments of the present disclosure. At the leaves of architecture 1000 are any number of processing nodes 1005 and 1010 object memories 1035. These object stores 1035 may each have an object index describing objects and portions of objects that are currently stored locally in the object store 1035. Some object memory 1035 (which may be a DDR4-DIMM interface compatible card within a single node in some embodiments) is logically connected to an object memory fabric node object index 1040. Object store structure node object indexes 1040 may each have an object index describing objects and portions of objects currently stored locally and/or currently stored in object store 1035. In some embodiments, the object memory fabric node object index 1040 may be instantiated as a PCIe card. With some embodiments, the object memory fabric object memory DDR4-DIMM and the object memory fabric node object index PCIe card may communicate over PCIe and memory buses.

In some embodiments, the object store fabric node object index 1040 operates in a similar manner as the object index within the object store 1035, except that the object store fabric node object index 1040 tracks all objects and portions of objects within any object store 1035 connected and maps objects and portions of objects to a particular object store 1035. The next level in the tree is a node object router object index 1020 that may be provided by an object memory fabric router that performs the same object index function on all object memory fabric node object indices 1040 to which it is connected. Node object router object indexes 1020 may each have an object index describing objects and portions of objects that are currently stored locally in lower levels (e.g., 1040, 1035). Thus, according to some embodiments, a router module may have directory and router functions, while a memory module may have directory and router functions, as well as memory functions to store memory objects. However, other embodiments are possible, and in alternative embodiments the router module may additionally have a memory function to store memory objects.

The schema that may be illustrated by structure 1000 may continue to a higher level inter-node object router object index 1015, and object router object index 1015 may be provided by an object memory fabric router performing the same object index function for all object memory fabric node object indexes to which it is connected, and so on, up to the root of the tree. Thus, in some embodiments, each object index and each level may independently perform the same function, but aggregating object indexes and levels into a tree network may provide a real-time dynamic distributed index with great scalability that effectively tracks and localizes memory objects and blocks. The additional attribute may be that the combination of tree, distributed index and cache enables a significant reduction in bandwidth requirements. This may be illustrated by the neighborhood of hierarchical indications depicted by the object memory fabric router as leaves (in this case downward). As the level of the defined hierarchy increases, so does the aggregate object memory caching capability. Thus, when an application working set fits within a given level of aggregate capacity, the bandwidth requirement on the root-oriented level may become zero.

As disclosed herein, each processing node is configured to be operably coupled to one or more additional processing nodes using a set of algorithms to operate as a set of processing nodes independent of the scale of the set of processing nodes. The set of nodes may operate such that all memory objects of the set of nodes are accessible by any node of the set of processing nodes. At the processing node, the object memory module may store and manage memory objects (each of which is instantiated locally therein and managed at the memory layer), as well as an object directory (which indexes memory objects and their blocks on a per object basis). The memory module may process a request, which may be received from an application layer, based at least in part on one or more object directories. In some cases, the request may be received from one or more additional processing nodes. In response to the request, a given memory module may process an object identifier corresponding to the given request and may determine whether the memory module has the requested object data. If the memory module has the requested object data, the memory module may generate a response to the request based at least in part on the requested object data. If the memory module does not have the requested object data, the object routing module may route the first request to another node in the tree. The routing of the request may be based at least in part on the object routing module making a determination regarding the location of the object data in response to the request. If the object routing module identifies a location based at least in part on the directory function of the object routing module, the object routing module may route the request down to the location (i.e., the node having the lower level of the requested object data). However, if the object routing module determines that the location is unknown, the object routing module may route the request to the root node (i.e., to one or more higher level object routers-inter-node object routers) to further make the determination at each level until the requested object is located, accessed, and returned to the original memory module.

In addition, as disclosed herein, triggers may be defined for objects in object metadata and/or blocks within objects. Object-based triggers can predict what operations will be needed and can provide acceleration by performing the operations in advance. When a node receives a request to specify an object (e.g., using a 128-bit object address), the node uses the object directory to determine whether the node has any portion of the object. If so, the object directory points to each-object tree (a separate tree whose size is based on the size of the object), which can be used to locate the block of interest locally. There may be additional trigger metadata, where for a particular block of interest, when the block is transferred to/through the memory module, it indicates that the particular address is interpreted in a predefined manner. The triggers may specify one or more predefined hardware and/or software actions on a per block basis relative to one or more blocks of data within the object (e.g., acquire a particular address, run a more complex trigger program, perform pre-fetching, calculate the other three blocks, and send signals to software, etc.). Triggers may correspond to hardware means to dynamically move data and/or perform other actions as an object flows through any memory module of an object memory fabric before such actions are required. Accordingly, such an action may be implemented when a particular memory object having one or more triggers is located at a respective memory module and accessed as part of the respective memory module processing one or more other requests.

Fig. 11 and 12 are block diagrams illustrating examples at the logical level of how the distributed nature of an object index operates hierarchically and interoperates with an object store structure protocol, according to some embodiments of the present disclosure. Some embodiments of object memory fabric protocol layering may be similar to conventional layered communication protocols, but with important differences. The communication protocol may be substantially stateless, but embodiments of the object store architecture protocol may maintain object state and implement distributed and parallel execution directly without any centralized coordination.

FIG. 11 illustrates an object memory hit condition 1100 that is executed entirely within object memory 1135, in accordance with certain embodiments of the present disclosure. Object store 1135 may receive processor request 1105 or background trigger activity 1106. The object memory 1135 may manage the local DRAM memory as the cache 1130 based on the processor physical address. The most common situation is probably that the requested physical address exists and it is immediately returned to the processor, as shown at 1110. The object memory 1135 can transparently move data from the slower flash memory to the fast DRAM memory using flip-flops, as shown at 1115.

For the miss case 1115 or background trigger activity 1106, some embodiments may include one or a combination of the following. In some embodiments, an object memory fabric object address may be generated from the physical address, as shown in block 1140. The object index may generate a location in local flash memory from the object address space, as shown in block 1145. Object index lookup can be accelerated by two methods: (1) hardware-based assistance for index lookup; and (2) the results of the object index lookup are cached locally. The object memory fabric cache coherency may be used to determine whether the local state is sufficient to satisfy the intended operation, as indicated by block 1150. Based on the index, a lookup may be performed to determine whether the object and/or blocks within the object are local, as shown in block 1155. In the event of a hit 1160, data corresponding to the request 1105 or the trigger activity 1106 may be transferred, as shown at 1165. Also, in some embodiments, when the cache state is sufficient, a decision may be made to cache the block into DRAM.

FIG. 12 illustrates a case 1200 of an object store miss and the distributed nature of the object store and object index, according to some embodiments of the present disclosure. The object store 1235 may undergo the steps described previously, but the routing/decision stage 125 may determine whether the object and/or block is local. As a result, the algorithm may involve requesting traversal 1270 of the tree up toward the root until an object/block is found. Any number of levels and corresponding node elements may be traversed until an object/block is found. In some embodiments, in each step along the path, the same or similar process steps may be followed to independently determine the next step on the path. No central coordination is required. Additionally, if disclosed herein, the object store structure APIs and triggers are typically executed in the leaf, but may be executed in a distributed fashion at any index.

As a simplified example, in the case shown, a request traverses 1270 up from the object store structure node object index 1240 corresponding to object store 1235 to object router 1220. Object router 1220 and its object router object index may identify the requested object/block as down the branch toward object memory fabric node object index 1241. Thus, at the index of object router 1220, the request may then be routed 1275 towards the leaf(s) of the providable object/block. In the example shown, object store 1236 may supply objects/blocks. At object store 1236, memory access/cache 1241 (which may include the previously described process steps for the hit case of execution) may be performed, and objects/blocks may be returned 1280 to original request leaf 1235 for final return 1290. Again, in some embodiments, at each step along the path, the same or similar process steps may be followed to independently determine the next step on the path. For example, original request leaf 1235 may perform the previously described process step 1285 for the hit case, and then return 1290 the requested data.

As disclosed herein, the operation of a single object store structure index structure, an object store structure index structure, may be based on several layers of the same tree implementation. Some embodiments using a tree structure may have several uses within an object memory structure, as described in table 4 below. However, various other embodiments are possible.

Fig. 13 is a block diagram illustrating an example of a leaf-level object store structure 1300 that is a distributed object store and index structure in view of the object store structure, according to some embodiments of the present disclosure. In some embodiments, leaf level object store structure 1300 may include a set of nested B-trees. The root tree may be an Object Index Tree (OIT) 1305, which may index locally existing objects. The index of the object index tree 1305 may be the object memory structure object address because the object starts from object size modulo zero. For each object (which has at least a single block stored locally in object memory), there may be one object index tree 1305.

The object index tree 1305 may provide one or more pointers (e.g., local pointers) to one or more of each object index tree (POIT) 1310. For example, there may be every object index tree 1310 per local object. Each object index tree 1310 may index object metadata and blocks belonging to locally existing objects. Each object index tree 1310 She Zhixiang is a corresponding metadata and block (e.g., based on an offset within the object) in DRAM1315 and flash 1320. The leaves of a particular block may be directed to DRAM1315 and flash 1320, such as in the case of leaf 1325. The organization of object metadata and data is further disclosed herein.

The tree structure used may be a modified B-tree of a copy-on-write (COW). COW is an optimization strategy that allows multiple tasks to efficiently share information without copying all banks, with most of the data unmodified. The COW stores the modified block in a new location, which is suitable for flash memory and caching. In some embodiments, the tree structure used may be similar to that of the open source Linux file system btrfs, with the main differences being the utilization of a single object/memory space, hardware acceleration, and the aggregation capability of the independent local indexes described previously. By utilizing multiple levels of the B-tree, there may be a higher degree of sharing and less fluctuation variation. Applications (e.g., file systems and database storage managers) can take advantage of this underlying efficient mechanism for higher level operations.

Fig. 14 is a block diagram illustrating an example of an object memory fabric router object index structure 1400 in accordance with some embodiments of the present disclosure. By some embodiments, the object store structure router object index and node object index may use nearly the same structure of object index tree 1405 and object index tree 1410 for each object. The object index tree 1405 may index locally existing objects. Each object described in object index tree 1405 may have each object index tree 1410. Each object index tree 1410 may index locally existing blocks and segments.

The object store structure router object index and node object index may index objects and blocks within objects that exist in child items 1415 within the tree structure 1400, i.e., child router(s) or leaf object store. Entries within the leaves in each object index tree 1410 have the ability to represent multiple blocks within an object. Because blocks of objects may tend to naturally aggregate together, and because of background management, each object tends to be represented more compactly in the object index closer to the root of the tree. The object index tree 1405 and each object index tree 1410 may allow for duplicate copies to be made at the object and block level, as multiple leaves may point to the same block, as in the case of leaves 1425 and 1430, for example. Index copy-on-write (COW) support allows, for example, only the blocks of an object to be updated to be modified.

15A and 15B are block diagrams of non-limiting examples of index tree structures according to certain embodiments of the present disclosure, including node index tree structure 1500 and leaf index tree 1550. Further non-limiting examples of aspects of the index tree field are identified in table 5 below. Other embodiments are possible. The separate index tree may include node blocks and leaf blocks. Each node or leaf block may include a variable number of entries based on type and size. The type specifies the node block, leaf, and/or type of leaf block, node.

The sizes specify the sizes of LPointer and Index Val (or object offset) independently. Within the balanced tree, a single block may point to all node blocks or all leaf blocks. To deliver the highest performance, the tree may become unbalanced, for example, where the number of levels of all paths through the tree are equal. Node blocks and leaf blocks may provide fields to support unbalanced trees. The background activity may rebalance the tree as part of other background operations. For example, an internal node (non-leaf) in the OIT may include LPointer and NValue fields. NValue may include an Object size and an Object ID. The Object ID requires 107 (128-21) bits to specify the smallest possible Object. Each LPointer may point to the next level of an internal node or leaf node. LPointer may need enough bits to represent all blocks in its local bank (about 32 bits to represent 16 TB). For nodes in POIT, NValue may consist of an object offset based on the object size. The object size may be encoded within the NSize field. The size field may enable a node to hold the maximum number of LPointer and nvqueue fields based on usage. The index tree root node may be stored in multiple locations on multiple flash memory devices to achieve reliable cold start of OIT. Root block updates may alternate between mirroring to provide wear leveling.

By default, each POIT Leaf entry may point to a location (e.g., 4 kbytes) of a single block. The POIT Leaf OM entry and the POIT Leaf Router (POIT Leaf Router) entry may contain a field to allow support beyond single block support, thereby enabling a more compact index tree, resulting in higher index tree performance and higher persistent storage performance by being able to match the page size of the persistent storage.

Nodes and leaves may be distinguished by a type field at the beginning of each 4k block. The NNize field may encode the size of the NValue field within the node and the LSize field may encode the size of the LValue field within the leaf. The size of the LPointer field may be determined by the physical addressing of the local memory bank fixed for the individual device (e.g., RDIMM, node router, or router). LPointer may be active only in a single device, rather than across devices. LPointer may specify whether the corresponding block is stored in persistent memory (e.g., flash memory) or higher speed memory (e.g., DRAM). A block stored in DRAM may also have a bank allocated within persistent memory so that there are two entries to indicate two storage locations of the block, node, or leaf. Within a single block type, all NValue and/or LValue fields may be a single size.

The OIT Node may include several Node level fields (Type), NSize, and lpagent) and include an OIT Node (OIT Node) entry or an OIT Leaf (OIT Leaf) entry. Since index trees may sometimes be unbalanced, a node may include both a node and a leaf entry. The POIT node may include one or more node level fields (e.g., type, NSize, and/or lpaent) and an entry including an OIT leaf entry. OIT leaf types can be distinguished by the otype field. The OTI Leaf may point to the header of POIT (per object index table) that specifies object blocks and object metadata. The OIT Leaf R may point to the distal header of the POIT. This may be used to reference objects residing on remote devices across a network. The leaf may enable the remote device to manage the object.

The POIT Leaf type may be distinguished by a ptype field. The POIT Leaf OM may point to a block or metadata of the object store. The Object offset field may be one bit larger than the number of bits to specify an offset of a particular Object size to specify metadata. For example, for 2 ²¹ May require 10 bits (9 plus 1 bit). Embodiments may choose to represent the offset in the form of a two's complement (symbol form, first block metadata is-1), or in the form of a two's complement (one's complement), where the additional bits represent metadata (first block of metadata is represented by 1, metadata bit set).

The POIT Leaf Remote may point to blocks or metadata of the object memory that are Remote from the local DIMM. This may be used to reference blocks residing on a remote device across a network through a stream packet interface. For example, the device may be a mobile device. The leaf may enable the object memory fabric hardware to manage consistency on a block basis for remote devices.

The POIT Leaf Router may be used within a node object Router and an inter-node object Router for specifying the state of a corresponding object memory fabric block object address for each of a maximum of 16 downstream nodes. If within the node object router, a maximum of 16 DIMMs may be specified in some embodiments (or more in other embodiments). If within the inter-node object router, up to 16 (more in other embodiments) downstream routers or node object routers (e.g., server nodes) may be specified in some embodiments. The block object address may exist in one or more downstream devices based on a valid state combination.

Index lookup, index COW update, and index cache may be directly supported in object memory, node object index, and object memory fabric hardware in the object memory fabric router. In addition to the node format of the object memory fabric index, an application defined index may be supported. These may be initialized through the object store structure API. An advantage of application-defined indexing may be that index lookup, COW update, index caching, and parallelism based on object-memory fabric hardware may be supported.

Various embodiments may provide for background operations and garbage collection. Since each DIMM and router within the object memory fabric can maintain its own directory and memory bank locally, background operations and garbage collection can be done locally and independently. Each DIMM or router may have a memory hierarchy for storing index trees and data blocks, which may include on-chip caches, fast memory (e.g., DDR4 or HMC DRAM), and slower non-volatile memory (e.g., flash memory) that it may manage, as well as index trees.

Each level within the hierarchy may perform the following operations: (1) tree balancing to optimize lookup time; (2) Reference counting and aging to determine when a block moves between different memory banks; (3) A free list update for each local level of the hierarchy, and a fill level parameter that maintains a primary level of the local hierarchy; (4) Delivering periodic fill levels to a next level of the hierarchy to enable load balancing of the memory banks between DIMMs on the local server and between levels of the object memory fabric hierarchy; (5) If the router, load balancing is performed among the child nodes.

The object memory fabric may use the block reference count to indicate the relative frequency of access. A higher value may indicate more frequent use over time, a lower value indicates less frequent use. When the block reference count is associated with a block in persistent memory, the block with the lowest value may be a candidate to move to another DIMM or node with more space available. The reference count may be incremented each time a block is accelerated into volatile memory. The low frequency background scan may decrement the value if the value is not in volatile memory and increment the value if the value is in volatile memory. It is contemplated that the scanning algorithm may evolve over time to be based on an increasing or decreasing amount or reference value, thereby providing an appropriate hysteresis. Blocks that frequently accelerate to or reside in volatile memory may have higher reference count values.

When the block reference count is associated with a block in volatile memory, the block with the lowest value may be a candidate to move back to persistent memory or memory within another DIMM or node. When a block is moved into volatile memory, a reference count may be initialized based on the instruction or use case that initiated the movement. For example, a demand miss may set the value to the midpoint and a speculative fetch (speculative fetch) may set it to a quarter point. A single use may set it to a point below quarter. A moderate frequency background scan may decrement the reference value. Thus, demand fetches may be weighted higher initially than speculative fetches. If speculative fetching is not used, it may quickly drop to a lower reference value that may be replaced first. Single use may be weighted lower as an earlier replacement candidate than other blocks. Thus, single-use and speculative blocks may not replace other frequently accessed blocks.

Fig. 16 is a block diagram illustrating aspects of an example physical memory organization 1600 in accordance with certain embodiments of the present disclosure. The object memory fabric may provide a variety of methods of accessing objects and blocks. For example, a direct method may be based on an execution unit in an object memory structure or device that may directly generate a complete 128-bit memory structure address, which may have complete direct access.

The associated method may consider a conventional server with limited virtual address and physical address space. The object memory fabric may provide an API to dynamically associate objects (e.g., segments) and blocks (e.g., pages) with a larger object memory fabric 128-bit memory fabric address. The associations provided by AssocObj and assoclk operations may be used by an object memory fabric driver (e.g., linux driver) and an object memory fabric system library (syselib) that interfaces with standard processor memory management to enable the object memory fabric to appear transparent to operating systems and applications. The object memory structure may provide: (a) An API that associates a range of processor segments and their virtual addresses with an object memory fabric object, thereby ensuring seamless pointer and virtual addressing compatibility; (b) An API that associates pages of virtual address space and corresponding object memory fabric blocks with pages/blocks of local physical memory within an object memory fabric DIMM (which may ensure processor memory management and physical addressing compatibility); and/or (c) local physical memory divided into standard conventional server DIMM slots, each DIMM slot having 512GB (2 ³⁹ Bytes). On a per slot basis, as shown in the following figures, the object memory fabric may hold an additional directory indexed by the physical address of the object memory fabric address of each block that has been associated with the corresponding physical address.

Fig. 16 is a block diagram illustrating an example physical memory organization 1600 in accordance with certain embodiments of the present disclosure. The physical memory directory 1605 for physical memory 1630 may include: object memory fabric object block address 1610; object size 1615; reference count 1620; modified field 1625, which may indicate whether the block is modified with respect to persistent memory; and/or write enable 1630, which may indicate whether the local block cache state is sufficient for writing. For example, if the cache state is a copy, then the write may be blocked and the object memory fabric will likely have sufficient state to write. On a boot-based object memory fabric DIMM SPD (serial presence detect) configuration, a physical address range may be assigned to each by the system BIOS.

Fig. 17A is a block diagram of an example object addressing 1700, according to some embodiments of the disclosure. FIG. 17B is a block diagram illustrating example aspects of object memory structure pointers and block addressing 1750, according to some embodiments of the disclosure. Object memory fabric object 1705 may include object data 1710 and metadata 1715, both of which are divided into 4k blocks as one unit of memory allocation in some embodiments, referenced by object memory fabric address space 1720. The object start address may be ObjectID 1755. Data 1710 may be accessed as a positive offset from ObjectID 1755. The maximum offset may be based on ObjectSize 1760.

Object metadata 1715 may be accessed as a negative offset from ObjectStart 1725 (ObjectID). Metadata 1715 may also be referenced by the object memory fabric address in the top 1/16 of object address space 1720. The start of the specific object metadata may be 2 ¹²⁸ -2 ¹²⁴ +ObjStart/16. This arrangement may enable the POIT to compactly represent the metadata 1715, and the metadata 1715 to have an object address space so that it may be managed as data consistently. Although the object data 1710 and metadata 1715 may be allocated a complete object address space, the banks may be sparsely allocated on a block basis. At a minimum, in some embodiments, the object 1705 has a single memory block allocated for the first block of metadata 1715. The object access rights may be determined by an object memory fabric file system ACL or the like. Since the object memory fabric manages objects in units of 4k blocks, the addressing in the object memory fabric object memory is a block address called block object address 1765 (BOA), which corresponds to object address space [127:12 ]]。BOA[11：0]Can be made of ObjectSize (BOA [ 7:0:0 ]]) And an object metadata indication (BOA [2:0]) Is used in the object memory.

Fig. 18 is a block diagram illustrating example aspects 1800 of object metadata 1805, according to some embodiments of the present disclosure. Table 6 below represents metadata for the first block 1810 of metadata 1805 for each of certain embodiments. In some embodiments, the first block 1810 of metadata 1805 may hold metadata for an object as shown.

The system-defined metadata may include any Linux-related data to seamlessly coordinate the use of certain objects across servers. The application-defined metadata may include application-related data from a file system or database storage manager to enable searches and/or relationships between objects managed by the application.

For objects with a small number of triggers, the base triggers may be stored within the first block; otherwise, the trigger B root may reference the metadata extension region of the corresponding object. The trigger B leaf may specify the base trigger. The base trigger may be a single trigger action. When more than a single action is required, a trigger may be invoked. When the triggers are invoked, they may reside in the extension area. The remote object table may specify objects accessible from the object through an extended instruction set.

Some embodiments may provide an extended instruction execution model. One goal of the extended execution model may be to provide a lightweight dynamic mechanism to provide memory and execution parallelism. The dynamic mechanism implements a dataflow execution method that enables a high degree of parallelism to be combined with varying tolerances of access delays of parts of the object. Work may be done based on actual dependencies rather than a single access delay delaying computation.

Various embodiments may include one or a combination of the following. The load and memory references may be split transactions with separate requests and responses such that the threads and memory paths are not utilized during the entire transaction. Each thread and execution unit is capable of issuing multiple loads to the object memory fabric (local and remote) before receiving a response. The object memory fabric may be a pipeline that processes multiple requests and responses from multiple sources so that memory resources may be fully utilized. The execution units may accept responses in a different order than the requests are issued. The execution unit may switch to a different thread to be fully utilized. The object store structure may implement policies to dynamically determine when to move an object or portion of an object, rather than move a thread or create a thread.

FIG. 19 is a block diagram illustrating aspects of an exemplary micro-thread model 1900 according to some embodiments of the disclosure. A thread may be a basic unit of execution. Threads may be defined at least in part by an Instruction Pointer (IP) and a Frame Pointer (FP). The instruction pointer may specify the current instruction being executed. The frame pointer may specify the location of the current execution state of the thread.

A thread may include multiple micro-threads. In the example shown, threads 1905 include micro-threads 1906 and 1907. However, a thread may include a greater number of micro-threads. The micro-threads of a particular thread may share the same frame pointer, but have different instruction pointers. In the example shown, frame pointers 1905-1 and 1905-2 specify the same location, but instruction pointers 1910 and 1911 specify different instructions.

One purpose of a micro-thread may be to enable data flow by enabling multiple asynchronous standby memory operations, such as operations within a thread. The micro-threads may be created by versions of fork (fork) instructions and may be rejoined by join instructions. The extended instruction set may treat the frame pointer as the top of a stack or register set by performing an operation on the offset from the frame pointer. Load and store instructions may move data between frames and objects.

Fig. 20 is a block diagram illustrating aspects of an example relationship 2000 of code, frames, and objects, according to some embodiments of the present disclosure. In particular, fig. 20 illustrates how object data 2005 is referenced by frames 2010. Default values may be used for load and store instructions to reference object 2005 in a local scope. Access to the objects 2005 outside the local scope can be given in a secure manner by access control and security policies. Once such access rights are given, objects 2005 in both local and non-local scope can be accessed with the same efficiency. The object memory architecture encourages strong security by encouraging efficient object encapsulation. By sharing frames, micro-threads provide a very lightweight mechanism to achieve dynamic and data flow memory and execution parallelism, e.g., on the order of 10-20 micro-threads or more. Multithreading achieves nearly infinite memory-based parallelism.

Fig. 21 is a block diagram illustrating an aspect of an example of micro-thread concurrency 2100, in accordance with certain embodiments of the present disclosure. In particular, fig. 21 shows a simple example of parallel data flow concurrency for summing values at several random positions. According to some embodiments of the present disclosure, serial version 2105 and parallel version 2110 are side-by-side. The parallel version 2110 can be almost n times faster because the loads are overlapping in parallel.

Referring again to fig. 20, the method can be extended to interactive and recursive methods in a dynamic manner. The advantage of advanced prefetching can now be achieved without the use of prefetching with minimal locality. When an object is created, a single default thread 2015 (a single micro-thread 2020 is created) may be waiting to start from the default thread 2015's start message. The default thread 2015 may then create a micro-thread using the thread, or create a new thread using a version of the fork instruction.

In some implementations, both the instruction pointer and the frame pointer can be limited to the extended metadata region 1815, with the extended metadata region 1815 starting at block 2 and extending to a segment size (SegSize)/16. As the number of objects, object size, and object capacity increase, thread and micro-thread parallelism may increase. Since threads and micro-threads can bind to objects, as objects move and allocate, so can threads and micro-threads. Embodiments of the object memory fabric may have dynamic selection of moving an object or portion of an object to a thread or assigning a thread to an object(s). This may be facilitated by a method of encapsulating objects implemented by an extended execution model.

In the foregoing description, for purposes of explanation, the methods were described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different than that described. It will also be appreciated that the methods described above may be performed by hardware components, or may be embodied in sequences of machine-executable instructions, which may be used to cause a machine (e.g., logic circuits programmed with the instructions or a general-purpose or special-purpose processor) to perform the methods. These machine-executable instructions may be stored on one or more machine-readable media, such as a CD-ROM or other type of optical disk, floppy disk, ROM, RAM, EPROM, EEPROM, magnetic disk or optical card, flash memory, or other type of machine-readable media suitable for storing electronic instructions. Alternatively, the method may be performed by a combination of hardware or software.

While illustrative and presently preferred embodiments of the invention have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed and that the appended claims are intended to be construed to include such variations except insofar as limited by the prior art.

Claims

1. An object memory fabric comprising:

A plurality of object memory modules, each object memory module comprising a single pluggable hardware module, and further comprising an object store storing one or more memory objects, memory object metadata, and a memory module object directory, wherein:

each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks; and

the memory module object directory indexes all memory objects and/or portions of memory objects within the object memory module; and

a hierarchy of object routers communicatively coupling the plurality of object memory modules, wherein:

each object router of the hierarchy of object routers maintains an object cache state for at least one memory object and/or portion of memory objects contained in an object memory module under the object router along a descent line in the hierarchy originating from the object router; and

based at least in part on the object cache state, the hierarchy of object routers is adapted to appear collectively as a single object directory communicatively coupled to all object memory modules, and to process requests based at least in part on the object cache state.

2. The object memory fabric of claim 1, wherein each object router of the hierarchy of object routers maintains a cache state for all memory objects and/or portions of memory objects contained in object memory modules under the object router along a descent line in the hierarchy originating from the object router.

3. The object memory fabric of claim 1, wherein the hierarchy of object routers operates according to a hierarchical tree network.

4. The object memory fabric of claim 3, wherein the object memory modules under the object router along the descent line in the hierarchy originating from the object router include object memory modules communicatively coupled directly to respective object routers toward leaves of a hierarchical tree network.

5. The object memory fabric of claim 4, wherein a leaf toward the hierarchical tree network corresponds to a most direct path between an object router away from a root of the hierarchical tree network and an object memory module at the leaf of the hierarchical tree network.

6. The object memory fabric of claim 1, wherein the aggregate appearing as a single object directory communicatively coupled to all object memory modules and processing the request comprises:

In response to each of the requests, at least one of the object routers examines the object cache state to determine whether a local object state is sufficient for an intended operation corresponding to the request, and:

forwarding the object to a leaf in the hierarchy after determining that the local object state is sufficient for the intended operation;

after determining that the local object state is insufficient for the intended operation, a first request is forwarded to a root in the hierarchy.

7. The object memory fabric of claim 1, wherein at least one of the requests is received from an application layer.

8. The object memory fabric of claim 1, wherein:

each object memory module further includes an object index tree that indexes the local memory objects;

the object index tree includes pointers to each object index tree of each local memory object; and

each object index tree of each local memory object maintains respective object cache states for memory object data and memory object metadata of a local representation of the local memory object.

9. The object memory fabric of claim 8, wherein each object index tree of each local memory object maintains respective object cache states for locally rendered memory object data and memory object metadata of the local memory object based at least in part on block status fields to track modifications of memory object data and memory object metadata relative to persistent and/or volatile memory.

10. A hardware-based processing node, comprising:

an object memory module comprising a single pluggable hardware module, and further comprising an object store storing one or more memory objects and memory object metadata, wherein each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks; and

an object router communicatively coupled to the object memory module, wherein the object router maintains an object cache state for at least one memory object and/or a portion of memory objects contained in an object memory module under the object router along a descent line in a hierarchy originating from the object router;

the object router processes one or more requests based at least in part on the object cache state.

11. The hardware-based processing node of claim 10, wherein processing the one or more requests comprises:

checking the object cache state to determine if the local object state is sufficient for an intended operation corresponding to the request, and:

12. The hardware-based processing node of claim 11, wherein forwarding a first request to a root in the hierarchy comprises routing the first request to an additional node.

13. The hardware-based processing node of claim 10, wherein at least one of the requests is received from an application layer.

14. The hardware-based processing node of claim 10, wherein:

the object memory module further includes an object index tree that indexes local memory objects;

15. The hardware-based processing node of claim 14, wherein each object index tree of each local memory object maintains respective object cache states for memory object data and memory object metadata of a local presentation of the local memory object based at least in part on the block status fields to track modifications of memory object data and memory object metadata relative to persistent memory and/or volatile memory.

16. The hardware-based processing node of claim 10, wherein at least one of the one or more requests is received from one or more additional nodes.

17. The hardware-based processing node of claim 10, wherein the node is configured to be operably coupled to one or more additional nodes using a set of algorithms to operate as a set of nodes and independent of the size of the set of nodes, wherein the set of nodes is operable such that all memory objects of the set of nodes are accessible by any node in the set of nodes.

18. A method of storing and managing one or more memory objects in an object memory fabric, the method comprising:

storing one or more memory objects and memory object metadata in an object store of an object memory module, the object memory module comprising a single pluggable hardware module, wherein each memory object and/or portion of a memory object is created locally within the object memory module and managed locally by the object memory module at a single memory layer without distinguishing between memory and memory banks;

maintaining, by an object router communicatively coupled to the object memory module, an object cache state for at least one memory object and/or a portion of a memory object in the object memory module, wherein the object memory module follows a descent line under the object router from a hierarchy of the object router; and

One or more requests are processed by an object router based at least in part on the object cache state.

19. The method of claim 18, wherein processing the one or more requests comprises:

20. The method of claim 19, wherein forwarding the first request to a root in the hierarchy comprises routing the first request to an additional node.