WO2017044126A1

WO2017044126A1 - Method call on an object in a parallel class hierarchy

Info

Publication number: WO2017044126A1
Application number: PCT/US2015/049737
Authority: WO
Inventors: Evan R. Kirshenbaum
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-09-11
Filing date: 2015-09-11
Publication date: 2017-03-16

Abstract

In some examples, a method includes identifying a method call to execute a dynamic function for a data object and determining a discriminator value associated with the data object. The method may further include indexing into a dispatch table using the discriminator value to access a caller function of a dispatch object. The dispatch object may be for a behavior class parallel to the data class of the data object in a parallel class hierarchy. The method may also include executing the caller function, which may include constructing a behavior object of the behavior class, calling a virtual function on the behavior object, and ensuring that the called virtual function has access to the data object.

Description

METHOD CALL ON AN OBJECT IN A PARALLEL CLASS HIERARCHY

BACKGROUND

[0001] With rapid advances in technology, computing systems are increasingly prevalent in society today. Vast computing systems execute and support applications that may communicate and process immense amounts of data, many times with performance constraints to meet the increasing demands of users. Increasing the efficiency, speed, and effectiveness of computing systems will further improve user experience.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description and in reference to the drawings.

[0003] Figure 1 shows an example of a system that supports a dynamic function call on a behavior object parallel to a data object in a parallel class hierarchy.

[0004] Figure 2 shows an example of a parallel class hierarchy.

[0005] Figure 3 shows an example of a dispatch table.

[0006] Figure 4 shows an example of behavior object generation through a creation function.

[0007] Figure 5 shows an example of a dynamic function call through a caller function.

[0008] Figure 6 shows an example of logic that a system may implement to support a virtual function call on a behavior object parallel to a data object in a parallel class hierarchy.

[0009] Figure 7 shows an example of a device that supports a virtual function call on a behavior object parallel to a data object in a parallel class hierarchy. DETAILED DESCRIPTION

[0010] The discussion herein may provide for methods, devices, systems, circuitry, and logic that support sharing of class objects between multiple, different processes that may execute simultaneously or at different times, including processes representing different executions of the same program or application. The shared class objects may be stored in a non-volatile memory of a computing system shared and accessible by multiple processes, programs, or compute nodes, for example. In particular, the features described herein may support class-specific behavior for the shared class objects, through a type-safe execution of virtual functions. A dynamic function may refer to a member function (or method) that is declared as part of the interface of a class but whose behavior upon invocation is based on a definition specified for a derived class (e.g., a subclass) and selected at runtime based on the particular subclass implemented by the object on which the method is invoked. The features described herein may provide for support for dynamic functions on a class-specific basis for data objects shared by multiple processes.

[0011] Within a running computer program or application, an object may be a data structure or other programmatic data element that resides, for a period of time, in a memory of a computer. Such memory may be referred to as process- local when it is only accessible by a single computer process running the program. The memory may be referred to as shared when it is accessible to multiple computer processes running the same or different programs on the same or different computers. Process-local memory may contain various types of data including data residing on heaps, on execution stacks for the process and for threads within the process, and in global and class-specific (or static) variables. Process-local memory may also contain instructions to be executed to perform program functions. Objects in a program may be referenced through references (or pointers) that refer to the objects. Objects and references may each be associated with a type in the program, where the type may indicate state that may be associated with the object (or the object referred to) and/or operations that may be invocable on the object (or the object referred to). [0012] Object types may include class types (also known as struct types or record types), and these types may be organized in a hierarchy, in which one class type (or class) may inherit from (or extend or derive from), one or more other classes. The notion that a (child) class B inherits from (or extends or derives from or is) a (parent) class A extends to the transitive closure. That is, class B may be said to inherit from class A even if it does so because class B inherits from class c and class c inherits from class A. When the distinction is important, class B may be said to directly inherit from class A when there are no intermediate classes in the class hierarchy. If class B (directly) inherits from class A, class B may be said to be a (direct) descendent (or subclass) of class A and class A may be referred as a (direct) ancestor (or superclass) of class B. A direct descendent may be called a child, and a direct ancestor may be called a parent (or base class).

[0013] A distinction may be made between the static type of an object and the dynamic type of the object. When an object is known through an object reference, the static type of the object may be inferred from the type of the reference, and this may be knowable via only the text of the program. When the same object is referred to by different references of different types, its static type may be determined to be different depending on the reference used to refer to it. The dynamic type of the object is a property of the object itself and may be established at the time the object is created. The dynamic type of an object may remain constant over the lifetime of the object, and it may be determined by reference to data associated with the object. For example, an object whose dynamic type is a class B, may be referred to or identified as a B (or as an instance of class B) and also to as an instance of any class A that may be an ancestor of class B. A programming language may require that the static type of an object, as seen via a reference to the object, be the type it was created as or an ancestor of that type.

[0014] An operation may be performed within a program by invoking (or calling) a function (or method or procedure). When such an operation is performed on an object as part of the object's class's interface, the operation may be called a method (or instance method or member function), and within the code defining such an operation the object on which the operation was invoked may be referred to as "this" or "self. Operations which are not performed on a particular object may be called global functions (or procedures) when they are not associated with a particular class and static (or class) methods (or member functions) when they are associated with a particular class. When an instance method is invoked on an object, the instructions to execute to perform the operation may be determined by either the static type of the object or the dynamic type of the object. If the dynamic type of the object is to be used, the method may be called a dynamic function (also referred to as a dynamic method) and the invocation of the method may be called a dynamic function invocation or dynamic method invocation. When the static type of the object is used, the method may be called a fixed method and the invocation of the method may be called a fixed method invocation.

[0015] For a dynamic method, the instance method may be declared in a class, which may license code to invoke the method on objects whose static class is known to be that class (or below it in the class hierarchy), but the actual implementation of the method may be specified in various classes below the declaring class in the class hierarchy. When a dynamic method is defined in one class and then redefined in a descendent class, the descendent may be said to have overridden the method. When a dynamic method is declared in a class but not defined, the method may be said to be an abstract method, and a method which has one or more abstract methods (via declaration or inheritance without defining) may be said to be an abstract class. A programming language may forbid instances to be constructed when the resulting dynamic class of the object would be an abstract class.

[0016] Within this specification, examples will be given in the C++ programming language (or C++). This should not be construed as limiting the scope of the application to programs written in C++. The C++ language provides direct support for a form of dynamic methods called "virtual functions" (or methods) and virtual functions which are methods may be called pure virtual functions (or methods). In C++, fixed method invocations (and other functions other than dynamic instance methods) may be implemented by directly transferring control to the instructions implementing the method, where the address of the instructions may be stored directly in the instructions for the program as a whole or may be determined and inserted into the proper locations at the time the program instructions are loaded into process-local memory.

[0017] To implement dynamic method dispatch for virtual functions, a C++ compiler may emit, as part of the static (or class-specific) data for a class that contains virtual functions, a virtual function table (or vtbl), which includes, for each virtual function, a pointer to the instructions implementing the virtual function for that class. The C++ compiler may also emit, as part of the instructions for creating an object for such a class, instructions to ensure that the object itself contains a pointer (which may be called a virtual function table pointer (or vtbl pointer) which points to the virtual function table for the object. To effect a dynamic method dispatch for a particular dynamic method on a particular object, the compiler may emit instructions to access the vtbl pointer from within the object, use this to identify the referenced virtual function table, identify from within the virtual function table the pointer to the instructions implementing the dynamic method, and make a (fixed) invocation of the referenced instructions. The term "virtual function" (or method) should not be read as limited to the use of that term with respect to the C++ programming language, but rather should be construed to refer to any mechanism for dynamic function dispatch provided by a programming language or library upon which the method described herein may be implemented.

[0018] If multiple processes within one or more computers access the same object within a shared memory (whether simultaneously or at different times), it may be problematic if the object contains, within its data, a pointer (or reference) that refers to an object (or instructions) within the process-local memory of any one of the processes. When a first process attempts to follow a pointer placed in a shared object by a second process and that pointer was intended to point into process-local memory local to the second process, the computer may interpret the pointer as pointing into the process-local memory local to the first process. The resulting address may not be loaded in the first process's process-local memory, which may result in a segmentation fault or other interrupt and may likely result in the first process crashing. Alternatively, the address may be valid for the first process but may refer to something completely different than what was intended by the second process, which may cause the first process to erroneously attempt to read, modify, or execute instructions and may also result in the first process crashing. For these reasons, it may be desirable to forbid programs from placing pointers into process-local memory within objects in shared memory. Since compilers may be configured to place virtual function tables and the instructions for implementing virtual functions in process-local memory, it may be desirable to forbid programs from placing into shared memory objects of types containing virtual functions, as the resulting vtbl pointers may be pointers into process-local memory. But since dynamic methods are useful, it may be desirable to have a method by which programs may invoke dynamic methods on objects that may be placed in shared memory without requiring these objects to contain vtbl pointers and without requiring modifications to C++ compilers to support virtual functions in another way.

[0019] The discussion below describes a parallel class hierarchy, dispatch table, and a dynamic function dispatch engine that may support class-specific behavior for shared class objects (e.g., objects contained in shared memory). As described in greater detail below, the parallel class hierarchy may include a behavior class hierarchy and a data class hierarchy with parallel inheritance structures. For a shared data object, the dynamic function dispatch engine may construct a corresponding behavior object of a behavior class parallel to the data class of the shared data object, e.g., via functions stored in dispatch objects in the dispatch table. The dynamic function dispatch engine may then call a virtual function associated with the dynamic function on the constructed behavior object, which may provide class-specific behavior for a shared data object.

[0020] The features described herein may efficiently and effectively provide class-specific behavior. In doing so, the parallel class hierarchy and dispatch table may be process-specific, and the class-specific behavior features described herein may be implemented without assumptions about the presence of other processes or about where instructions for implementing such class-specific behavior (e.g., the text segment of the process) are loaded into a process's virtual address space (e.g., by a process loader). Further, the class-specific behavior features provided herein may be compiler-independent in that implementation of the features described herein may be implemented without changes to a compiler or without dependence upon a specific compiler version or specific configuration parameters (e.g., runtime arguments) provided to the compiler when the program containing the classes is compiled. Thus, the features described herein may support multiple applications implementing the same class, even when the multiple applications are compiled using different compilers or different compiler versions. Many of the examples below are provided through a C++ programming language syntax. However, the features described herein may be similarly and consistently implemented across various programming languages, systems, and devices.

[0021] Figure 1 shows an example of a system 100 that supports a dynamic function call on a behavior object parallel to a data object in a parallel class hierarchy. The system 100 may take the form of any computing device or system, such as an application server, compute node, desktop or laptop computer, smart phone or other mobile device, embedded controller, and more. As such, the system 100 may execute multiple processes or application programs and support sharing of data (e.g., class objects) between the multiple processes. In some examples, the system 100 may include multiple computing devices capable of sharing data with one another. To support shared data, the system 100 may implement or provide a shared memory that the multiple processes may commonly access data from. The shared memory may be volatile memory (e.g., dynamic random-access memory or DRAM) or non-volatile memory (e.g., readonly memory or ROM, flash memory, memristor memory, spin-transfer torque memory, or volatile memory mapping a file stored on a device such as a disk or solid-state drive), [0022] The system 100 may provide class-specific behavior for class objects shared between processes. As described in greater detail below, the system 100 may provide class-specific behavior through a parallel class hierarchy with a data class hierarchy and a behavior class hierarchy and using a hierarchy-specific dispatch table to bind data and behavior together in a type-safe manner. As one example, the system 100 shown in Figure 1 includes a memory 102 that stores a dispatch table 104. The memory 102 may be any machine-readable medium, such as a random-access memory (RAM) such as a dynamic RAM (DRAM), flash memory, memristor memory, spin-transfer torque memory, an Electrically- Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.

[0023] The memory 102 storing the dispatch table 104 may be a process-local memory. In that regard, the memory 102 may be used by or assigned to a specific process, for example to implement a virtual memory space for the process. The system 100 may include multiple instances of process-local memory, each of which may store a dispatch table for a particular process executing on the system 100, though the various process-local memories may be implemented by the same physical memory device. The memory 102 storing the dispatch table 104 may be logically (and possibly physically) separate from a shared memory implemented or used by the system to access shared data objects. In that regard, the dispatch table 104 and the memory 102 storing the dispatch table 104 may be specific to a process, but the shared memory storing shared data objects may be accessible and used by other processes as well.

[0024] The system 100 shown in Figure 1 includes a dynamic function dispatch engine 110. The system 100 may implement the dynamic function dispatch engine 110 as executable instructions stored on a machine-readable medium, hardware, electronic circuitry, logic, or as any combinations thereof. In operation, the dynamic function dispatch engine 110 may access the dispatch table 104 to provide class-specific behavior for an object. As one example, the dynamic function dispatch engine 110 may identify a method call to execute a function for a data object of a data class; determine a discriminator value associated with the data object; index into the dispatch table 104 using the discriminator value to access a caller function of the dispatch object; and execute the caller function to construct a behavior object of the behavior class; call a virtual function on the behavior object; and ensure access to the data object for the execution of the virtual function.

[0025] Example features of the system 100, dynamic function dispatch engine 110, and the dispatch table 104 are described in greater detail next. In particular, the following discussion (including the discussion with respect to Figures 2-5) includes description regarding the parallel class hierarchy, dispatch table, dispatch table initialization, dispatch object functions, downcasting data, and a data-centric class example.

Parallel Class Hierarchy

[0026] Figure 2 shows an example of a parallel class hierarchy 200. A parallel class hierarchy may refer to two class hierarchies with parallel hierarchical structures. The parallel class hierarchy 200 shown in Figure 2 includes a behavior class hierarchy 201 that is parallel in structure to a data class hierarchy 202. The behavior class hierarchy 201 and data class hierarchy 202 may be parallel by sharing a common inheritance structure running through both hierarchies 201 and 202. To illustrate, if a behavior class B inherits (or derives) from behavior class A, then the data class parallel to behavior class B inherits (or derives) from the data class parallel to behavior class A (and vice versa).

[0027] In some examples, the parallel structure of the parallel class hierarchy 200 may be inexact, with one or more classes being omitted from either of the hierarchies 201 and 202, so long as each data class is associated with a behavior class (and vice versa). In these examples, the parallel class hierarchy 200 may have a characteristic that if a behavior class B inherits (directly or indirectly) from a behavior class A, the data class associated with behavior class B (e.g., parallel to behavior class B) is either the same as the data class associated with behavior class A or inherits (directly or indirectly) from it (and vice versa for behavior classes associated with data classes). [0028] A behavior class and parallel data class (or vice versa) may correspond to one another. The data class may define the data elements of a data object and the parallel behavior class may specify behavior applicable to the corresponding data class. In the parallel class hierarchy example shown in Figure 2, the behavior class in the behavior class hierarchy 201 shown as B-Class 211 corresponds to (e.g., is parallel) to the data class in the data class hierarchy 202 shown as D-Class 212. As such, the behavior class B-Class 211 and data class D-Class 212 share parallel inheritances within the behavior class hierarchy 201 and data class hierarchy 202 respectively. A data object of data class D-Class 212 may store data for the data object, and a corresponding behavior object of the behavior class B-Class 211 may define behavior specific to the data object. In some examples, the behavior defined by the behavior class B-Class 211 may be specified by reference to member functions defined within the data class D- class or another class inside or outside data class hierarchy 202.

[0029] The dynamic function dispatch engine 110 or other system logic may constrain a behavior object (e.g., an instance of a behavior class within the behavior class hierarchy 201 ) to be constructed within process-local memory. As such, a behavior class of the behavior class hierarchy 201 may contain or specify virtual methods. In some examples, a data object (e.g., an instance of a data class within the data class hierarchy 202) may be constructed by the dynamic function dispatch engine 110 (or other system logic) within the shared memory and, therefore in these examples, a data class of the data class hierarchy 202 may be constrained or restricted from containing virtual methods. In some such examples a data object may be constructed within either the process-local memory or the shared memory. In other such examples, the data object may be constrained to be constructed within shared memory (and not the process-local memory).

[0030] When a behavior object is constructed by the dynamic function dispatch engine 110 to hold a reference to a data object, invoking a virtual method on the constructed behavior object may be considered to be a dynamic method invocation on the data object. Alternatively, when the dynamic function dispatch engine 110 creates a temporary behavior object in response to a request to invoke a dynamic method on a data object and then invokes a virtual method on the constructed behavior object passing in a reference to the data object, this may also be considered to be a dynamic method invocation on the data object.

[0031] The parallel class hierarchy 200 shown in Figure 2 conceptually illustrates a behavior class hierarchy 201 parallel to a data class hierarchy 202. Specific implementations of the parallel class hierarchy 200 may vary. The system 100 and the dynamic function dispatch engine 110 may support parallel class hierarchies of various implementations, some of which are presented next. In some examples, the behavior class hierarchy 201 includes virtual member functions, e.g., the implementations of a dynamic function specific to the behavior classes of the behavior class hierarchy 201. To illustrate, the behavior class B- Class 211 may include a virtual member function implementing the dynamic function specifically for the behavior class B-Class 211 , and applicable to data objects of the data class D-Class 212 parallel to the behavior class B-Class 211.

[0032] Member functions of a dynamic function may be declared through the root of the behavior class hierarchy 201 , although the class-specific definitions of the member functions may or may be declared through the root. Member functions may also be declared lower in the behavior class hierarchy 201.

[0033] The dynamic function dispatch engine 110 may support access to a data class parallel to a behavior class. For example, for a behavior class B, the dynamic function dispatch engine 110 may support access to the parallel data class through identifying the type indicated by a well-known type name such as B : :data_type. The data_type identification may be implemented through aliasing (e.g., via the "typedef or "using" declarations in C++). In other examples, the dynamic function dispatch engine 110 supports access to the data class declared as a nested class having the well-known name within a behavior class, e.g., in the following format:

Thus, in this example, the data classes of a parallel class hierarchy 200 are nested within respective parallel behavior classes as the data type.

[0034] In some examples, the root of a parallel class hierarchy 200 is specified as follows:

In this example, the dynamic function dispatch engine 110 may recognize external_data as the root of the behavior class hierarchy 201 , parameterized by the class that heads the particular hierarchy (e.g., the Root type). The externai_data class may be aliased, for example as behavior_base. The dynamic function dispatch engine 110 may recognize the root of the data class hierarchy 202 as data_type_base, which may be nested within the external data class (e.g., nested within a corresponding, parallel behavior class, which in this example is the external_data class that is the root of the behavior class hierarchy 201 ).

[0035] The behavior class hierarchy 201 may include limited references to data members of the data class hierarchy 202. For example, the external_data class may include a reference to a data type base object, but not to other data members. Subclasses in the behavior class hierarchy 201 may add or include references to other data members according to limited data member inclusion exceptions. As one example of a data member inclusion exception, a subclass in the behavior class hierarchy 201 may add a data member used to augment a method (e.g., a cache), provided there is no assumption or requirement that other behavior objects representing a specific shared object data will likewise share the added data member. As another example of a data member inclusion exception, a subclass of the behavior class hierarchy 201 may add a static (e.g., class-shared) data member as long as there is no assumption or requirement that other different processes will share the added data member.

[0036] The data_type_base class may include a discriminator. The discriminator may take the form of a numerical value (or any other value that can be coerced, mapped, or otherwise translated to a numerical value, e.g., a Boolean value, a character value, or a member of an enumerated type). In some examples, the discriminator may take the form of a non-numeric value (e.g., a string or record) that can be used as a lookup key in an associative data structure (e.g., a map, hash table, key-value store, or database table). A discriminator value may uniquely identify a particular behavior class in the behavior class hierarchy 201. In systems in which multiple parallel class hierarchies 200 share a single dispatch table 104, a discriminator value may uniquely identify a particular behavior class among all of the sharing behavior class hierarchies 201.

[0037] In some example systems, there may be behavior classes in the behavior class hierarchy that may not be uniquely identified by discriminator values. In some example systems, multiple discriminator values may identify the same behavior class. Data classes in the data class hierarchy 202 used to create data objects may also be associated with discriminator values identifying the associated (e.g., parallel or correlated) behavior class to use when interacting with the data object. Data classes which are constrained (e.g., by programming- language-specific mechanisms) or not intended to be used directly to create data objects (e.g., those that can or will never be the dynamic type of a data object) may not have associated discriminator values. In some example systems, the association between data classes and discriminator values may not be unique, for example multiple data classes may share the same discriminator value (and behavior class), and a single data class may allow its data objects to be constructed with multiple alternative data values representing multiple alternative behavior classes.

[0038] The dynamic function dispatch engine 110 may use the discriminator as an index into the dispatch table 104, as described below. The discriminator may include various characteristics, supporting class-specific behavior for shared class objects. For example, the discriminator may be known at compile time, unique from other discriminator values for other classes in the same hierarchy, and may be configured to remain constant while any instances of data objects for the specific class are active or "live".

[0039] The data type base class in a parallel class hierarchy 200 may define a constructor that takes a discriminator as a parameter. The data type base class may also define a move constructor, a copy constructor, or both. In some examples, data classes in the data class hierarchy 202 may respectively define a constructor that takes a discriminator as a parameter and passes the discriminator to the constructor of its parent class. One such example is shown as follows:

In this example, the constructor for the data class B : : data type includes an optional discriminator parameter, which may default to the discriminator value of behavior class B. The discriminator value of behavior class B may be passed up along with any parameter used to initialize the data for parent class(es) of B.

[0040] To further illustrate using the example above, the data class hierarchy 202 of a parallel class hierarchy 200 may support the construction of a data object of class A through the following:

new A: : data_type (5.0)

The construction above may result in a data object includes the fields of class A (as well as the fields of any parents of class A) including the discriminator value of class A. In some examples, further parameters provided to the "new" operator may direct that the construction of the data object take place in a region of memory available to multiple processes, such as a shared non-volatile memory. As another example of construction, the data class hierarchy 202 may support the construction of a data object of class B through the following:

new B : : data_type (5.0, 1)

The construction above may result in a data object that further includes the fields of class B and has a discriminator value of class B. Accordingly, the data class hierarchy 202 may support construction of data objects with a class-specific discriminator value according to the particular data class of a constructed data object. Put another way, the data class hierarchy 202 may support construction of data objects without explicit specification of a discriminator value for the data class of the constructed data object.

[0041] Turning to the constructors for the behavior class hierarchy 201 , a behavior class in the behavior class hierarchy 201 may define a constructor that takes a reference to a data object of a corresponding (e.g., parallel) data class, such as a data object of a class that is or derives from the class that is the data type of the behavior class. The constructor may pass the data object reference to the constructor of the parent class of the behavior class. In this way, the behavior class hierarchy 201 may guarantee that the data_type_base reference held by the parent external_data class is of the corresponding type, allowing for safely down-casting of data that the constructed behavior object is bound to. By specifying to the compiler that it should or may in-line constructors in the behavior class hierarchy 201 , the behavior class hierarchy 201 may provide for efficient construction of a behavior object through assigning two pointers: one to the referenced data object and one to virtual table of the behavior class.

[0042] As described above, the system 100 may support a parallel class hierarchy 200 including a behavior class hierarchy 201 parallel to a data class hierarchy 202. The parallel class hierarchy 200 may support class-specific behavior for shared data objects. For example, the discriminator value of a particular data object may be used along with a dispatch table 104 to identify a dispatch object within the dispatch table 104 including various functions providing class-specific behavior through constructed behavior object of a behavior class parallel to the data class of the particular data object. The dispatch table 104 is discussed next.

Dispatch Table

[0043] Figure 3 shows an example of a dispatch table 104. The system 100 may implement the dispatch table 104 as a hierarchy-specific class, e.g., for a particular parallel class hierarchy 200. In systems containing multiple parallel class hierarchies 200, each parallel class hierarchy 200 may have its own dispatch table 104 or, if discriminator values are not duplicated between the data classes in the respective data class hierarchies 202, multiple parallel class hierarchies 200 may share a single dispatch table 104. Continuing the examples described above, the dispatch table 104 may be accessed, for example, as external_data : : dispatch_table_type. The system 100 may implement the dispatch table 104 as any data structure, such as a vector, array, hash table, or in various other forms.

[0044] The dispatch table 104 may store dispatch objects, such as the dispatch objects labeled as 301 , 302, and 303 in Figure 3. The dispatch table 104 may include dispatch objects associated with behavior classes in the behavior class hierarchy 201 of the parallel class hierarchy 200. A dispatch object of the dispatch table 104 may include any number of functions to support class-specific behavior for shared data. When a dispatch object contains only a single function, that function may be considered to be the dispatch object itself. Three example functions are shown in Figure 3 as the dispatch object 301 includes a creation function 311 , a deleter function 312, and a caller function 313. These functions are discussed in greater detail below.

[0045] The dispatch table 104 may support access to particular dispatch objects through discriminator values. In that regard, the discriminator value of a data object of a particular data class in the data class hierarchy 202 may be used as an index into the dispatch table 104 to identify a particular dispatch object for a behavior class parallel to the particular data class. To illustrate through the example shown in Figure 3, the dispatch object 301 is referenced by a discriminator index 321 , which may be the discriminator value for data objects of a data class parallel to the behavior class associated with the dispatch object 301. Similarly, the dispatch object 302 is accessed through the discriminator index 322 and the dispatch object 303 is accessed through the discriminator index 323.

[0046] The dispatch table 104 may be process-specific. In that regard, different processes, applications, or programs accessing shared data may each use a respective dispatch table to support class-specific behavior. For a data object shared by multiple processes, a first process of the multiple processes may access the dispatch table 104. A second process of the multiple processes may access a different dispatch table, which may be stored on a different memory of a different computing node executing the second process, for example.

Dispatch Table Initialization

[0047] The system 100 may initialize the dispatch table 104 prior to access by the dynamic function dispatch engine 110. To guarantee that initialization takes place before first use, the dispatch table 104 may be implemented as a static variable within a static dispatch_table () method of the external_data class associated with the parallel class hierarchy 200. Initialization of the dispatch table 104 may include calling a static init_dispatch_table () method of the external data class, passing in an uninitialized table. The initialization may ensure (e.g., by using the C++ standard caii_once () function) that the dispatch table 104 is initialized once, instead of multiple times. The init_dispatch_table ( ) method may include one or more calls to a bind ( ) method of the dispatch table 104, where each call may be used to create a dispatch object associated with a behavior class in a behavior class hierarchy 201 and associate it in the dispatch table 104 with a discriminator value associated with that behavior class.

[0048] An implementation of the dynamic function dispatch engine 110 in the form of a library may require that the implementation of the init_dispatch_table () method (or an equivalent description of the set of calls to bind ( ) methods) be provided by the programmer designing the parallel class hierarchy 200. The bind ( ) method calls may create the dispatch objects in a process-local memory (e.g., the memory 102) rather than a shared memory. An example implementation of the init_dispatch_table () method for a class external_data<Root> (e.g., representing a behavior class hierarchy 201 rooted at a class named Root) may include:

In initializing the dispatch table 104, the bind() methods may be respectfully parameterized by a class below Root class in the parallel class hierarchy 200 (e.g., a behavior class below the externai data class in the behavior class hierarchy 201). The bindo method associated (e.g., through a template parameter) with a class τ below Root in the hierarchy may take an optional discriminator parameter, which may default to T::discrim (e.g., the discriminator value associated with class τ). For the class τ, the bind ( ) method may create one or multiple lambda functions (e.g., anonymous functions) corresponding to functions included in a dispatch object, collect the lambda functions together into a dispatch object, and insert the dispatch object into the dispatch table 104, e.g., at an appropriate point to support access to the dispatch object according to the provided or default discriminator.

Dispatch Object Functions

[0049] Next, some example functions that dispatch objects within a dispatch table 104 may include and which the dynamic function dispatch engine 110 may access are described. Example functions include the creation function 311, deleter function 312, and caller function 313 shown in Figure 3.

[0050] Figure 4 shows an example of behavior object generation through a creation function 311. The dynamic function dispatch engine 110 may execute the creation function 311 to generate a corresponding behavior object for a data object. A dispatch object as described herein may include or omit any of the described functions and may include other functions to be used by the dynamic function dispatch engine 110 as well.

[0051] The creation function 311 may take a reference (e.g., pointer) to a data object 410 and determine that the data object 410 is of a particular data class in the data class hierarchy 202, such as data class D-Class 212, or is of a data class that derives from D-Class 212. This determination may be based on the fact that the discriminator value contained within the data object 410 was associated with a discriminator index 321 , for example, and led the dynamic function dispatch engine 110 to identify dispatch object 301 within dispatch table 104. Then, the creation function 311 may construct a corresponding behavior object of the behavior class parallel to the data class of the data object 410, shown in Figure 4 as the behavior object 420 of the behavior class B-Class 211 parallel to the data class D-Class 212 of the data object 410. The creation function 311 may construct the corresponding behavior object in process-local memory (e.g., on a process-local heap). The creation function 311 may also ensure access to the inputted data object, such as by constructing the behavior object to refer to the inputted data object. Thus, in the example shown in Figure 4, the behavior object 420 generated by the creation function 311 may refer to the data object 410. The creation function 311 may return the corresponding behavior object as a return value, such as by returning a pointer to the corresponding behavior object.

[0052] The dynamic function dispatch engine 110 may execute the creation function 311 in response to identifying a method call to create a corresponding behavior object associated with the data object 410. For example, the dynamic function dispatch engine 110 may identify or implement a method calls for the dispatch table 104 itself or methods called on a data_type_base object (and thus, data objects of any data class in the data class hierarchy 202).

[0053] To illustrate, the dispatch_table_type class may include methods which take a data_type_base reference and dispatch the reference to the appropriate dispatch object (and function within the dispatch object) according to the discriminator value of the data_type_base reference. Thus, the dispatch table class (e.g., dispatch_table_type) may include a create (data) method which the dynamic function dispatch engine 110 may implement or perform to determine the discriminator value for the data object data and index into the dispatch table 104 using the determined discriminator value to access a corresponding dispatch object and execute the creation function 311 of the corresponding dispatch object.

[0054] As the dispatch table 104 itself may be hidden within the external_data class, the dynamic function dispatch engine 110 may identify method calls on a data_type_base object (and hence, on data objects of any data class in the data class hierarchy 202). As one example, the dynamic function dispatch engine 110 may identify, implement, or perform a bind ( ) method that calls dispatch_table () . create (*this) . That is, the dynamic function dispatch engine 110 may identify the bindo method called on a data type base object to create a corresponding behavior object for the data object. In response to identifying the bind ( ) method called on a data object, the dynamic function dispatch engine 110 may create a behavior object (e.g., on a heap) corresponding to the data object the bind ( ) method is called on and return a pointer to the corresponding behavior object. In doing so, the dynamic function dispatch engine 110 may execute the create (data) method of the dispatch table 104 and the creation function 311. Virtual functions called on the corresponding behavior object may dispatch to the correct version, e.g., the appropriate virtual member function implemented by the behavior class of the corresponding behavior object.

[0055] The deleter function 312 (not shown in Figure 4), may take a reference to a data object of a data class in the data class hierarchy 202 and delete the data object. The deleter function 312 may provide class-specific behavior for shared class objects particularly when a data class includes a destructor, ensuring that the data object and all of its contents are correctly destroyed. Thus, the deleter function 312 may support class-specific deleting of shared data objects and the dynamic function dispatch engine 110 may execute the deleter function 312 to delete a data object.

[0056] The dynamic function dispatch engine 110 may execute the deleter function 312 in response to identifying a method call to delete a data object. As noted above, the dispatch_table_type class may include methods which take a data_type_base reference and dispatches the reference to the appropriate dispatch object (and function within the dispatch object) according to the discriminator value of the data_type_base reference. As such, the dispatch table class dispatch_tabie_type may include a release (data ptr) method which the dynamic function dispatch engine 110 may implement or perform to determine the discriminator value for the data object referenced by the data ptr and index into the dispatch table 104 using the determined discriminator value to access a corresponding dispatch object and execute the deleter function 312 of the corresponding dispatch object.

[0057] As another example, the dynamic function dispatch engine 110 may identify or perform a method call on a data_type_base object (and hence, data objects of any data class in the data class hierarchy 202) to delete the data object. In particular, the dynamic function dispatch engine 110 may identify a release () method called on the data_type_base object, and in turn call dispatch_table () .release (this) . Thus, in response to identifying the release ( ) method called on a data object, the dynamic function dispatch engine 110 may delete the data object. In doing so, the dynamic function dispatch engine 110 may execute the release (data_ptr) method of the dispatch table 104 and the deleter function 312.

[0058] Figure 5 shows an example of a virtual function call through a caller function 313. The dynamic function dispatch engine 110 may execute the caller function 313 to call a virtual function on a data object, which may thus provide class-specific behavior to shared data objects.

[0059] The caller function 313 may take, as inputs, a reference (e.g., pointer) to a data object 510 and a function 512, which may be a dynamic function. The data object 510 may be of a particular data class, such as the data class D-Class 212 shown in Figure 5. The function 512 may be declared to accept, as an argument, a reference to an object whose type is the behavior class associated with the data object 510. A pointer to a virtual member function of the behavior class (or of a class from which the behavior class derives) may be specified as the provided function 512. In executing the caller function 313, the dynamic function dispatch engine 110 may construct (e.g., on the process stack) a behavior object of the behavior class parallel to the data class of the data object 510, shown in Figure 4 as the behavior object 520 of the behavior class B-Class 211 parallel to the data class D-Class 212 of the data object 510.

[0060] The dynamic function dispatch engine 110 may ensure that the constructed behavior object 520 has access to the data object 510. For example, the dynamic function dispatch engine 110 may construct the behavior object 520 to refer to the data object 510. Executing the caller function 313 may cause the dynamic function dispatch engine 110 to call a virtual function 522 associated the function 512, passing in as an argument the behavior object 520 that refers to the data object 510. Doing so may result in calling the virtual member function of the behavior class B-Class 211 , which may thus provide class-specific behavior for the data object 510. Put another way, the dynamic function dispatch engine 110 may call, as the virtual function 522, the virtual member function of the behavior of the behavior object 520 providing class-specific behavior for the dynamic function 512.

[0061] The dynamic function dispatch engine 110 may execute the caller function 313 in response to identifying a method call to execute a virtual function for a data object. As noted above, the dynamic function dispatch engine 110 may identify or implement a method calls for the dispatch table 104 itself or methods called on a data type base object (and thus, data objects of any data class in the data class hierarchy 202).

[0062] To illustrate, the dispatch table class dispatch_table_type may include a call_through (data, function) method which the dynamic function dispatch engine 110 may implement or perform to determine the discriminator value for the data object data and index into the dispatch table 104 using the determined discriminator value to access a corresponding dispatch object and execute the caller function 313 of the corresponding dispatch object, passing the data object data and function function to the caller function 313. In some examples, the call_through (data, function) method may be implemented as a template method. In some examples, the caller function 313 may expect a function (e.g., the function 512) that does not return a value.

[0063] In some examples, the dynamic function dispatch engine 110 may implement or execute one of two different versions of the call_through (data, function) method, conditioned on whether the function argument returns a value or not. When the function argument does not return a value, the dynamic function dispatch engine 110 may simply call the caller function 313 passing in function argument as the function 512. When the function argument returns a value, the dynamic function dispatch engine 110 may implement the caii_through (data, function) method to create a local variable on the program stack, where the type of the local variable is the type to be returned by function. A second function may be created (e.g., as a lambda function), which may call the provided function and store the result in the local variable. The method may then invoke the caller function 313 passing in the second function as the function argument to the caller function 313. When the caller function 313 returns, the value of the local variable may be returned as the value of the method.

[0064] The dynamic function dispatch engine 110 may identify, implement, or perform a call_through (func) method, and doing so may return the result of executing dispatch_table () .call_through (*this, func). In some examples, the caii through method may be configured to take extra parameters (e.g., through function templates) that may be passed in as arguments to the provided function 512. Such methods may be implemented by constructing additional functions (e.g., as lambda functions) which do not take parameters but which internally invoke the provided function passing in the provided arguments as extra parameters.

[0065] To provide another illustration for the call_through method, a pointer rp to a Root : : data_type may point specifically to a data object whose class is B: :data_type (e.g., of a data class parallel to and nested within behavior class B). As described above, the static type of the data object, when accessed via pointer rp may therefore be Root : : data_type, while its dynamic type may be B : : data_type. The method Root : : vm ( ) may refer to a dynamic function defined (e.g., a virtual function) on objects of type Root and any subclass thereof. In this illustration, the dynamic function dispatch engine 110 may identify the following call as a method call to execute a dynamic function on a data object:

rp -> call_through (&Root : : vm)

In identifying the above call, the dynamic function dispatch engine 110 may execute the caller function 313 for a dispatch object of the dispatch table 104 accessed (e.g., indexed) through the discriminator value of the data object referred to by rp. In doing so, the dynamic function dispatch engine 110 may create a behavior object of behavior class B and cause the constructed behavior object to refer to the object referred to by rp. Then, the dynamic function dispatch engine 110 may call vm( ) on the constructed behavior object, resulting in the calling of B : : vm ( ) and thus providing class-specific behavior using the dispatch table 104 and parallel class hierarchy 200. Downcasting Data

[0066] In performing a member function implemented in a behavior class, the dynamic function dispatch engine 110 may require access to the data of the data object bound to or referenced by a behavior object. To access the data, the dynamic function dispatch engine 110 may perform, use, or implement a data_for () method. As one example, the dynamic function dispatch engine 110 may use the following data_for call for the behavior class B:

data_for<B> ( )

In this example, the method data_for ( ) may be a method declared on type externai_data<Root> and parameterized by a behavior class deriving from Root. Calling this method may return a reference to the data object associated with the behavior object, considered as (e.g., statically cast as) a reference to an object of type B : : data type (e.g., the data type associated with class B) . In using the above data for call, class B may be required to be the behavior class defining the virtual member function (or an ancestor).

[0067] As another example, the dynamic function dispatch engine 110 may use the following data_for call:

data_for (bptr)

where data_for (bptr) may be a method declared on type externai_da- ta<Root> and bptr may be a pointer to an instance of a behavior class deriving from Root. In this example, the data_for call may return a reference to the data object associated with the behavior object rerferred to by pointer bptr, downcast to the data type associated with the (static) type of the behavior object point to. When the argument provided to this method is the behavior method's this pointer, as in a call to data_for (this) , the dynamic function dispatch engine 110 may ensure that the data bound to the current behavior object downcast to the current behavior object's data type.

Data-Centric Classes Example

[0068] The examples above include a parallel class hierarchy 200 implemented through a behavior class externai_data as the root of the behavior class hierarchy 201 and through the nesting of data classes within behavior classes. As another example, the parallel class hierarchy 200 may include the data class hierarchy 202 and nest (or alias) the behavior classes of the behavior class hierarchy 201 within the data classes of the data class hierarchy 202. Put another way, system 100 may support a parallel class hierarchy 200 with the data class hierarchy 202 as the main class, and the behavior classes as nested classes within the data classes.

[0069] In the example above, data classes of the data class hierarchy 202 may derive from the root class identified as, for example, with_dynamic_methods. As such, the root of the parallel class hierarchy 200 may be specified as:

As seen in the example above, a data class in the data class hierarchy 202 may include (or otherwise refer to) a nested behavior class dynamic_methods within the behavior class hierarchy 201 , which may derive from the dynamic methods class associated with the root data class of the data class hierarchy 202, where this dynamic_methods class itself derives from the dynamic_methods_base Class nested within with_dynamic_methods.

[0070] The dynamic_methods classes in the behavior class hierarchy 201 may contain virtual functions (and in some examples, only virtual functions), and some of these virtual functions may be pure virtual functions (e.g., functions which are declared but not defined), rendering the containing behavior classes abstract classes. When such pure virtual functions are defined, the dynamic functions may be implemented by calling corresponding methods on the data class associated with the behavior class. Such calls may be non-virtual method invocations and may be accomplished by invoking the call_non_dynamic () method, defined in the with_dynamic_methods class, on a data object of the corresponding data class. [0071] In this data-centric example, the data classes of the data class hierarchy 202 may implement the behavior of the classes, but invocations of these implementation methods need not involve the mechnanism provided by the C++ compiler for implementing virtual function dispatch or other dynamic method dispatch mechanisms which may traverse the requirements on objects placed in shared memory. The dynamic functions are implemented by (non-virtual) methods on the data classes which call a call_dynamic () method, passing in a reference to a (virtual) method on the corresponding behavior classes (e.g., the nested dynamic_methods classes). This results, through the dynamic function dispatch engine 110 identifying a dispatch object corresponding to the data object's discriminator value and a caller function within the dispatch object, in a behavior object of the appropriate type being created and the virtual function being invoked on it. The definition of the virtual function will turn around and call the call_non_dynamic o method, passing in a (non-virtual) implementation on the appropriate data class. This in turn will result in the implementation method being called (as a fixed call) on the data object, completing the dynamic function call.

[0072] As a concrete example, the parallel class hierarchy 200 may include the following data class at the top of the hierarchy for the type Operation":

}

The parallel class hierarchy 200 may also include the following data class as a sub-class of the data class above:

[0073] With the example above, the dynamic function dispatch engine 110 may identify a non-virtual call to the apply () method on an object known (via static typing on a reference to it) to be an Operation data object but which was constructed specifically as an Add data object. In response, the dynamic function dispatch engine 110 may determine a discriminator value of the Add data object, and index into a dispatch table 104 to access a dispatch object indexed by the discriminator value of the Add data object. In this example, dispatch objects of the dispatch table 104 may include the caller function 313, but may or may not include other functions. Thus, in some implementations, the dispatch table 104 may include dispatch objects that only include the caller function 313.

[0074] The dynamic function dispatch engine 110 may execute the caller function 313 accessed using the discriminator value of the Add data object, which may cause the dynamic function dispatch engine 110 to construct a behavior object of the Add: :dynamic_methods class (e.g., on the stack). Then, the dynamic function dispatch engine 110 may call the virtual apply ( ) function of the constructed behavior object, and passing in the Add data object as a parameter. In doing so, the dynamic function dispatch engine 110 may call the non-dynamic call_non_dynamic ( ) function on the passed-in Add data object, passing in the appiy_impi ( ) method of the Add data object (e.g., implemented in the example above as return argl+arg2). Then, the apply_impl ( ) method of the Add data object may be called, which may result in class-specific behavior for the Add data object (that is, applying the class- behavior of the Add object). Thus, in the example above, the parallel class hierarchy 200, dispatch table 104, and dynamic function dispatch engine 110 may support a call to a non-virtual implementation of a function in the appropriate subclass without having an actual virtual function pointer (or virtual function table) in a shared memory.

[0075] As illustrated in the above example, a virtual function may take as a parameter a reference to an object of a data class associated with the behavior class in which the virtual function was declared (e.g., the self parameter of the apply ( ) operation). In such systems the objects in the behavior class hierarchy 201 need not refer to corresponding objects in the data class hierarchy 202. Instead, the dynamic function dispatch engine 110 may ensure that calls to the call_dynamic ( ) method will result in an appropriately-typed parameter being passed to the virtual function, where this data object reference may be suitable for invoking the call_non_dynamic ( ) method and passing in a reference to a (non-virtual) member of the inferred data class. As the ultimate method invocation may be on an object of the correct data class (e.g., the this pointer within the method may point to an object of the correct data class), downcasting within the implementation method may be unnecessary.

[0076] To ensure that the arguments passed are of the correct class, the call_dynamic () method may take the form of a template function that may accept, in addition to the arguments required by the dynamic method, a pointer to a data object and a reference to a method on the behavior class associated with the static class of the pointer. The dynamic function dispatch engine 110 may constrain the static class of the pointer to be in the data class hierarchy 202 and the method may be constrained to accept the pointer to the data object in addition to the pointer to the provided arguments. In the example above, the dynamic Operation: : apply () method accepts two integer parameters and calls call_dynamic () passing in this (e.g., a pointer to an object of class Operation) and a reference to Operation : : dynamic_methods : : apply ( ) (e.g., a method which takes a pointer to an object of class operation and two integers). Within the implementation of call_dynamic ( ) , the dynamic function dispatch engine 110 may identify a dispatch object within the dispatch table 104 based on the discriminator value associated with the data object. The dynamic function dispatch engine 110 may call (e.g., invoke) the caller function of the dispatch object, passing in a function (e.g., a lambda function) that accepts a reference to the behavior object created by the caller function and invokes the provided method on that behavior object, passing in the reference to the data object and the dynamic method arguments.

[0077] Further, the call_non_dynamic () method may take the form of a template function that may accept, in addition to the arguments required for the dynamic method, a reference to a method on a data class. The dynamic function dispatch engine 110 may constrain the method to accept the dynamic method arguments and where the data class should be (and may be constrained to be) the data class on which the dynamic method (e.g., the method that invoked call_dynamic () ) was declared or a subclass of that method. Within the implementation of call_non_dynamic ( ) , the dynamic function dispatch engine 110 may assume (e.g., through a C++ static cast operator) that the object on which call_non_dynamic ( ) was invoked is of a type suitable for having the argument method invoked on it, and the dynamic function dispatch engine 110 may, therefore, invoke the method on the (suitably cast) operator.

[0078] To illustrate through the above example, the definition of Add: :dynamic_methods: : apply ( ) accepts a pointer to an Operation, matching the declaration of the apply ( ) method in the Operation: :dynamic_methods class. Within the method definition, the apply ( ) method causes the dynamic function dispatch engine 110 to invoke the caii_non_dynamic ( ) method on the referenced operation object, passing in a reference to the apply_impl ( ) method on the Add class. This will result in the Operation object being assumed to be an Add object and the (fixed) method invoked on it by the dynamic function dispatch engine 110. This assumption is correct, since the discriminator value associated with the Operation data object will result in the dynamic function dispatch engine 110 creating an Add: :dynamic_methods behavior object (e.g., if the discriminator value is Operation: :discrim) if the Operation is, indeed, an instance of class Add.

[0079] As described above, a system 100 may include a dispatch table 104 and dynamic function dispatch engine 110 that provide class-specific behavior for shared data objects through a parallel class hierarchy 200. The features described above may provide class-specific behavior for shared class objects for a particular process without assumptions about the presence of any other processes and without assumptions about where text segments (e.g., the parts of the process address space that contain instructions) are loaded into a virtual address space of a process.

[0080] Moreover, the features described herein may support class-specific behavior while also allowing for compilation of different programs or applications using the same shared data (even simultaneously) at different optimization and debugging levels, or compilation using different compilers or compiler versions. In that regard, the class-specific behavior features provided by the dispatch table 104 and dynamic function dispatch engine 110 may be transparent to or independent of a compiler, providing class-specific behavior without requiring any changes to a compiler. As yet another benefit, the features described herein may allow different programs to use the same shared data while associating different behavior with the data (e.g., via the respective behavior class hierarchies 201 of the different programs).

[0081] Figure 6 shows an example of logic 600 that a system 100 may implement to support a dynamic function call on a behavior object parallel to a data object in a parallel class hierarchy 200. The system 100 may implement the logic 600 to in the form of hardware, executable instructions stored on a machine- readable medium, or as combinations thereof. As one example, the system 100 may implement the logic 600 through the dynamic function dispatch engine 110, and the dynamic function dispatch engine 110 may perform or execute the logic 600 as a method or process to perform a virtual function call on a behavior object parallel to a data object in a parallel class hierarchy 200.

[0082] The dynamic function dispatch engine 110 may identify a method call to execute a dynamic function for a data object of a data class in a parallel class hierarchy (602) and determine a discriminator value associated with the data object (604). Then, the dynamic function dispatch engine 110 may index into a dispatch table 104 using the discriminator value to access a caller function 313 of a dispatch object (606), the dispatch object for a behavior class parallel to the data class of the data object in a parallel class hierarchy 200. The dynamic function dispatch engine 110 may execute the caller function 313 (608), which may include constructing a behavior object of the behavior class (610); calling a virtual function associated with the dynamic function on the behavior object (612), and ensuring that the called virtual function has access to the data object (614). The virtual function may be a virtual member function of the behavior object, for example. In a data-centric example, calling the virtual function may result in the calling of a non-virtual function on the data object. Ensuring that the called virtual function has access to the data object may include constructing the behavior object to reference the data object passing a reference to the data object as a parameter to a virtual function call for the virtual function. [0083] In some examples, the dynamic function dispatch engine 110 may construct the behavior object on a stack, also referred to as an execution stack, program stack, or process stack. The stack may refer to a stack data structure storing information or runtime data for a computing program. In this example, the behavior object may disappear as the stack clears. The dynamic function dispatch engine 110 may also initialize the dispatch table 104, including constructing the dispatch object for the behavior class to include the caller function, identifying the discriminator value as associated with the behavior class; and inserting the dispatch object for the behavior class according to the discriminator value.

[0084] In some examples, the dynamic function dispatch engine 110 may further identify a method call to create a corresponding behavior object associated with the data object, including in any of the ways described above regarding the create (data) method of the dispatch table 104 and the bind() method. In response, the dynamic function dispatch engine 110 may determine the discriminator value specific associated with the data object, index into the dispatch table 104 using the discriminator value to access a creation function 311 of the dispatch object; and execute the creation function 311. Executing the creation function 311 may include constructing the corresponding behavior object of the behavior class parallel to the data class of the data object, ensuring that the constructed behavior object refers to the data object, and returning the corresponding behavior object as a return value for the method call.

[0085] In some examples, the dynamic function dispatch engine 110 may further identify a method call to delete the data object, for example through the release (data_ptr) method of the dispatch table 104 or the release () method described above. In response, the dynamic function dispatch engine 110 may determine the discriminator value specific to the data class of the data object, index into the dispatch table using the discriminator value to access a deleter function 312 of the dispatch object, and execute the deleter function to delete the data object of the data class. [0086] The data object may be used, shared, or otherwise commonly accessible to multiple processes. For example, some or all of the multiple processes may perform at least one of following operations on the data object: read a state within the data object; modify the state within the data object; invoke a method on the data object; store a reference to the data object; and/or pass a reference to the data object as a parameter to a function.

[0087] In such examples, the dynamic function dispatch engine 110 may index into the dispatch table 104 for a first process among the processes and index, using the discriminator value associated with the data object, into a different dispatch table (e.g., stored in a different process-local memory) for a second process among the multiple processes that is different from the first process.

[0088] Figure 7 shows an example of a device 700 that supports a virtual function call on a behavior object parallel to a data object in a parallel class hierarchy. The device 700 may include one or more processors 710, and the processor 710 may include a central processing unit (CPU), microprocessor, or any hardware device suitable for executing instructions stored on a machine- readable medium. The device 700 may include a machine-readable medium 720. The machine-readable medium 720 may be any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the instructions 722, 724, 726, 728, and 730 shown in Figure 7. As such, the machine-readable medium 720 may be, for example, Random Access Memory (RAM) such as a dynamic RAM (DRAM), flash memory, memristor memory, spin-transfer torque memory, an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.

[0089] The device 700 may execute instructions stored on the machine- readable medium 720 through the processor 710. Executing the instructions may cause the device 700 to perform any combination of the features described herein, including according to any features of the dynamic function dispatch engine 110. For example, executing the instructions 722, 724, 726, 728, and 730 may cause the device 700 to maintain a dispatch table 104 that includes a dispatch object for a behavior class parallel to a data class in a parallel class hierarchy, the dispatch object including a caller function 313; identify a method call to execute a dynamic function for a data object of a data class; determine a discriminator value associated with the data object; index into the dispatch table 104 using the discriminator value to access the caller function 313 of the dispatch object; and execute the caller function to construct, on a stack, a behavior object of the behavior class, call a virtual function on the behavior object, and ensure that the virtual function has access to the data object.

[0090] In some examples, the machine-readable medium 720 may further include executable instructions that, when executed by the processor 710, cause the device 700 to identify a method call to delete the data object, and in response, determine the discriminator value associated with the data object; index into the dispatch table 104 using the discriminator value to access a deleter function 312 of the dispatch object; and execute the deleter function 312 to delete the data object of the data class. As another example, the machine-readable medium 720 may further include executable instructions that, when executed by the processor 710, cause the device 700 to identify a method call to create a corresponding behavior object for a data object of a data class, the corresponding behavior object of the behavior class parallel to the data class, and in response, determine the discriminator value associated with the data object; index into the dispatch table 104 using the discriminator value to access a creation function 311 of the dispatch object; and execute the creation function 311 to construct the corresponding behavior object of the behavior class, ensure that the corresponding behavior object refers to the data object, and return the corresponding behavior class as a return value for the method call.

[0091] The systems, methods, devices, circuitry, and logic described above, including the dynamic function dispatch engine 110, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the dynamic function dispatch engine 110 may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including any features of the dynamic function dispatch engine 110.

[0092] The processing capability of the systems, devices, logic, and circuitry described herein, including the dynamic function dispatch engine 110, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a dynamic link library (DLL)). The DLL, for example, may store code that performs any of the system processing described above.

[0093] While various examples have been described above, many more implementations are possible.

Claims

1. A method comprising:

identifying a method call to execute a dynamic function for a data object of a data class in a parallel class hierarchy;

determining a discriminator value associated with the data object;

indexing into a dispatch table using the discriminator value to access a caller function of a dispatch object, wherein the dispatch object is for a behavior class parallel to the data class of the data object in the parallel class hierarchy; and

executing the caller function, including:

constructing a behavior object of the behavior class; calling a virtual function associated with the dynamic function on the behavior object; and

ensuring that the called virtual function has access to the data object.

2. The method of claim 1 , wherein constructing the behavior object comprises constructing the behavior object on a stack.

3. The method of claim 1 , further comprising initializing the dispatch table, including:

constructing the dispatch object for the behavior class to include the caller function;

identifying the discriminator value as associated with the behavior class; and

inserting the dispatch object for the behavior class according to the discriminator value.

4. The method of claim 1 , further comprising identifying a method call to create a corresponding behavior object associated with the data object, and in response: determining the discriminator value associated with the data object; indexing into the dispatch table using the discriminator value to access a creation function of the dispatch object; and

executing the creation function, including:

constructing the corresponding behavior object of the behavior class parallel to the data class of the data object;

ensuring that the constructed behavior object refers to the data object; and

returning the corresponding behavior object as a return value for the method call.

5. The method of claim 1 , wherein multiple processes each perform at least one of the following operations on the data object:

read a state within the data object;

modify the state within the data object;

invoke a method on the data object;

store a reference to the data object; or

pass a reference to the data object as a parameter to a function.

6. The method of claim 5, wherein indexing into the dispatch table comprises indexing into the dispatch table for a first process among the multiple processes; and

further comprising indexing, using the discriminator value associated with the data object, into a different dispatch table for a second process among the multiple processes that is different from the first process.

7. A system comprising:

a memory storing a dispatch table, the dispatch table comprising a dispatch object specific to a behavior class parallel to a data class in a parallel class hierarchy; and

a dynamic function dispatch engine to: identify a method call to execute a dynamic function for a data object of the data class;

determine a discriminator value associated with the data object; index into the dispatch table using the discriminator value to

access a caller function of the dispatch object; and execute the caller function to:

construct a behavior object of the behavior class;

call a virtual function associated with the dynamic function on the behavior object; and

ensure access to the data object for execution of the virtual function.

8. The system of claim 7, wherein the dynamic function dispatch engine is further to identify a method call to delete the data object, and in response:

determine the discriminator value associated with the data object;

index into the dispatch table using the discriminator value to access a deleter function of the dispatch object; and

execute the deleter function to delete the data object of the data class.

9. The system of claim 7, wherein the dynamic function dispatch engine is further to identify a method call to create a corresponding behavior object associated with the data object, and in response:

determine the discriminator value associated with the data object;

index into the dispatch table using the discriminator value to access a creation function of the dispatch object; and

execute the creation function to construct the corresponding behavior object of the behavior class parallel to the data class of the data object and return the corresponding behavior object as a return value for the method call.

10. The system of claim 9, wherein the dynamic function dispatch engine is to return the corresponding behavior object as the return value by returning a pointer to the corresponding behavior objected constructed through the creation function.

11. The system of claim 7, wherein the data object is shared by multiple processes.

12. The system of claim 11 , wherein the dispatch table is used by a first process of the multiple processes; and

wherein the memory further stores a different dispatch table used by a second process of the multiple processes.

13. A non-transitory machine-readable medium storing executable instructions to:

maintain a dispatch table that includes a dispatch object for a behavior class parallel to a data class in a parallel class hierarchy, the dispatch object including a caller function;

identify a method call to execute a dynamic function for a data object of a data class;

determine a discriminator value associated with the data object;

index into the dispatch table using the discriminator value to access the caller function of the dispatch object; and

execute the caller function to:

construct, on a stack, a behavior object of the behavior class; call a virtual function associated with the dynamic function on the behavior object that references the data object; and

ensure that the virtual function has access to the data object.

14. The non-transitory machine-readable medium of claim 13, wherein the executable instructions are further to identify a method call to delete the data object, and in response:

determine the discriminator value associated with the data object; index into the dispatch table using the discriminator value to access a deleter function of the dispatch object; and

execute the deleter function to delete the data object of the data class.

15. The non-transitory machine-readable medium of claim 13, wherein the executable instructions are further to identify a method call to create a corresponding behavior object for the data object, the corresponding behavior object of the behavior class parallel to the data class of the data object, and in response:

determine the discriminator value associated with the data object; index into the dispatch table using the discriminator value to access a creation function of the dispatch object; and

execute the creation function to construct the corresponding behavior object of the behavior class, ensure that the corresponding behavior object refers to the data object, and return the corresponding behavior class as a return value for the method call.