CA2097542C - Linkage for accessing data objects in the stack - Google Patents
Linkage for accessing data objects in the stackInfo
- Publication number
- CA2097542C CA2097542C CA002097542A CA2097542A CA2097542C CA 2097542 C CA2097542 C CA 2097542C CA 002097542 A CA002097542 A CA 002097542A CA 2097542 A CA2097542 A CA 2097542A CA 2097542 C CA2097542 C CA 2097542C
- Authority
- CA
- Canada
- Prior art keywords
- heap
- data object
- storing
- index
- class
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
Abstract
When an object call from the stack results in the invocation of a hierarchy of class constructs on a memory heap, a base class removed more than a predetermined number of levels from the derived class whose member object was called from the stack, has no means of directly accessing the originating program in the stack to implement an independent task outside the invocation chain. Means for creating a record of the address of the originating point in the executing program or the return address in the object's heap allocation that is accessible to all base classes in the invocation chain is provided to permit direct access to the originating activation record in the stack for base classes having independent task constructors.
Description
2097~2 LINKAGR FOR ACCESSING DATA OBJECTS IN TEE STACK
The present invention is directed to establishing a link mechanism in run-time memory for relating object structures with the stack structure in a consistent yet optimal manner in an object-oriented computing environment.
Two major types of object-oriented language technologies have arisen since first introduction of the concept through Simula1, pure object-oriented languages such as SmallTalk2 develop~d to embrace the object-oriented approach, and compiled object-oriented languages such as C++3 that aim to optimize run-time in object-oriented technology. The present invention is directed to such compiled object-oriented language technology as C++.
Object oriented technology, in general, approaches the computer simulated modelling of real-world processes and modularization for building complex computer systems, by focusing on representing physical objects and the relationships between them, rather than on abstract procedures as in conventi,onal programming.
,~ .
The computer simulated "objects" in object-oriented technology are defined and maintairled independently of each other, the definit,;,on of an object i.ncluding its "methods"
(what procedures or operations t,he object is capable of performing) and i.ts "variables" (its attributes, the values of which can change over ti,me). This independence in definition or existence is felt to be more consistent with the way in which humans view the world, and provides a natural way of breaking down a problem to be solved, thus Simula is a modular programming language developed in the late 1960's at the Norwegian Computing Center.
SmallTalk was developed in the early 1970's at Xerox PARC (Palo Alto Research Center), California, as a complete object-oriented language.
C+~ was developed in the early 1980's at AT~T's Bell Laboratories as a 2~9754~
facilitating the construction of very complex computer systems and working models based on numerous components.
In object-oriented systems, objects are defined through class definitions. A "class" is a template that defines the methods and variables to be included in a particular type of object. Classes can be defined in terms of other classes, that is, the characteristics (methods and/or variables) of a class (a "subclass") can be "inherited" from a superior, more generalized class (a "base" class).
In addition to the methods and variables they inherit, subclas~e~ define their own methods and variables and this may include characteristics permitting the override of inherited characteristics, although the implementation of such derived classes is visible only within the class to prevent contamination of other class implementations.
An abstract class is a base class with no object members or "instances", the sole purpose of which is to organize a class hierarchy or define methods or variables that will apply to a lower level inherited class.
Since inherited methods and variables can be more narrowly defined, or even redefined in a derived class, base classes are often described as "po]ymorphic", that is, having the ability to hide different impletnentations behind a common interface, simplifying the commullicatioll among objects.
Objects defined through this technology can be highly specialized and can fit within a complex system of related, but not identical, ohjects, arld class hierarchies can encompass many levels.
In many computer systems, static storage mechanisms known as "class libraries" serve as repositories for the class hierarchy and data, and when a class is called through a preprocessor enhancement, adding object-oriented features to the already existing C language.
~0~54~
processor, channel the appropliate data to the run-time memory.
Both the C l~ngl1~ge and its object-oriented enhancement C++ (as well as other object-oriented languages) require the allocation of dynamic storage from the operating system at run-time. This run-time storage is allocated as two separate areas known as the "heap" and the "stack". Current data objects and information associated with only one activation within the compiled program are allocated to the stack for the life of the particular activation, Objects (such as classes in C++) cont~ining data that could be accessed over more than one activation must be heap allocated or static for the duration of use during run-time.
Because any data objects in a derived class declared on the stack are visible only from within the object to which the stack belongs, a problem arises where a class library defines a base class that needs to perform a task abstraction such as some action directly on an active object of a derived class beyond the first level of inheritance.
In order to implement the direct action, the base class must be able to locate and access the active object's variables declared on the stack. However, because the base class was not itself called from the stack, the only way for it to jump to the proper location in the stack is to locate the address or return address stored in the first data object called after object creation, in order to return to the origin~ting point in the executing program.
In the presence of an a-bi~l~ly number of levels of inheritance between the base class and the derived class called from the stack, the base class has no means of identifying the derived class containing the return address and directly acces.cing the location of the active data object in the stack.
One application in which this problem may arise is that of effecting concurrent threads of control discussed in my simultaneously filed Canadian patent application No. 2,097,41, entitled , .
~ ~ 9 ~ 5 4 2 "Controlling Method Invocation Sequence through Virtual Functions in an Object-Oriented Class Library".
C++ is an inherently sequential object-oriented l~n~ e without any provision for concurrent processing of independent applications or threads of control in an application. Yet as concurrency optimizes run-time, it would be a desirable feature in such a l~n~l~ge.
One approach to providing concurrency has been through the virtual class mech~ni~m, adding a special "Task" class in the class library whose function is to implement concurrent processing.
Class libraries such as Doeppner4, implement an "active object" abstraction based on a four-class "tasking" package. In these types of applications, it is the job of the Task class to spin off an independent thread of control for instances of any class for which the Task class is a base class.
When the new thread of control has been generated, the Task class directs the original thread to jump to the point in the program (called the origin~ting point) which immediately follows the invocation of the constructors, while the other thread continues executing the original task invoked in the program.
Other proposals for specific abstract "task like" classes are for directed purposes, as in U.S.
Patent No. 5,142,674 - Barker et al, relating to the use of an abstract class in an object-oriented document or local library for constructing application dependent indices to an object-oriented document database for random object retrieval.
In the example of Doeppner, the problem of the Task class not knowing where to look for the address of the Doeppner, T., Gebele, A., "C++ on a Parallel Machine", Technical Report CS-87-26, Brown University Department of Computer Science, November 1987.
f~
~as7~
ori~in~tin~; point in the program is dealt with by limiting the levels of inheritance to a known number. Similarly, in Barker, the database parameters are known from the outset.
The only other solution proposed to date to this problem is to abandon the use of a class library and to use an enhanced compiler or l~ngl1~ge extensions, as described in more detail in copending Canadian Patent Application No. 2,097,451.
It is therefore an object of the present invention to provide, in compiled object-oriented technologies such as C++ that use a standard non-extended compiler, a means for relating object structures in the heap with the stack in a consistent manner, without regard to the number of levels of class inheritance.
This is addressed in the present invention by manipulating one of the registers or variables in each object constructed on the heap to point back to an activation record in the stack. In particular, the invention provides means for storing in every base class constructed on the heap a variable directly identifying the location of an active record in the stack through which the address of the ori~in~ting point in the calling program can be accessed.
Accordingly, in one aspect, in a compiled object-oriented l~ngu~ge operating system having an operating program, a dynamic memory stack and at least one activation record allocated on the stack for the operating program, and a dynamic memory heap for allocating and subsequently constructing a data object derived from a class hierarchy called from the operating program, the present invention provides a mech~ni~m for locating the original activation record from a pre-selected base class for the data object having means for storing an index to the original activation record in the data object on allocation of the data object . ~. ; .
,?
CA9-93-008 6 ~a$75~L~
on the heap, and means for accessing the index on construction of the pre-selected base class on the heap. Preferably, the means for storing an index to the original activation record has means for locating multiple words in the data object allocated on the heap and means for storing said index in a predetermined word in the data object allocated on the heap.
According to another aspect of the invention, in a compiled C++ operating system having a program adapted to operate in the system, a memory stack adapted to allocate at least one activation record to the program for execution of an activation and a memory heap adapted to allocate storage that is static over multiple activations to a data object in a class hierarchy called in said program, a mechanism for linking data objects allocated on the heap with said at least one activation record is provided that includes means for storing an index to the at least one activation record in a data object on allocation of the data object on the heap and means for accessing the index on construction on the heap of a pre-selected base class for the data object.
Preferably, the means for storing an index comprise means for storing a stack pointer denoting an origin~ting point in the program.
The present invention also provides a method for linking a base class in a class hierarchy constructed on a memory heap with an activation record allocated on a memory stack for a program calling a derived data object in the class hierarchy and operating in a compiled object-oriented computer system. The method is the computer implemented steps of allocating the derived data object on the memory heap as a data object heap allocation, storing an index in the data object heap allocation to the activation record, and accessing the index on construction ofthe base class on the memory heap.
, 2097~42 Embodiments of the invention wil] now be described in detail in association with the accompanying drawings, in which:
Figure 1 is a flow diagram outlining the computer implemented steps in creating and accessing a linkage to the stack according to one embodiment of the invention;
Figure 2 is a schematic representation of a portion of dynamic stack memory for a processor at the start of execution of the method of the invention; and Figure 3 is a schematic representation of a portion of dynamic stack memory for a processor on construction of a base clas.3 to access the stack, according to the invention.
When an activation record on the stack issues a call to a data object in a class library in an object-oriented environment such as Cl~-, the called data object and all its superior or base classes are constructed or allocated on the heap in the following manner. Constructors in each class in the class hierarchy point to and cal]. (invoke~ the base class from whic}l the objec~. valiables for the class are derived, so that every ti.me a ~ata object is created, a series of constrl.lctors is invoked for al] classes in the class hierarchy.
In normal implementatiorls of COnstl~lCtOl~ i.nvocation in C++, suffici.ent space for the new]y allocated object, including all its levels of inheritallce in its c]ass hierarclly, is allocated OTI the ~leap, and i.ts constructor is called. This will be the constructor defined ~or the class having the deepest level of inheri.1-ance (eg., ]evel A).
C++ specifies that the class constructors for base classes be executed before derived class constructors are executed.
Thus, before its own execution, the constructor at the deepest level of inheritance (level A) will immediately call the constructor for its base class (level B) at the second deepest level of inheritance. The called base class (level B~ will in turn immediately call its own base constructor (level C), and so on, until the constructor for the highest 20975~2 , abstract class (level T) is called. Once this constructor for the highest abstract class (level T) finishes and returns, the constructor that called it (level C or higher) will perform its constructioll duties (which may involve calling constructors for member objects), and will then return to the constructor (level B) that called it. This process continues until the first constructor (level A) is allowed to do its construction. This process is referred to as the invocation chain.
The invocation chain includes the creation of a record for each base class o~ the c].ass t.hat called it to permit a return to the cal.].ing class on completion of construction of the called base c]ass. However, this inter-class record is restricted to a single leve] of inheritallce; there is no mechanism for a base class to cletermine which class in the hierarchy initiated the invocation chain and actually contains a record of the location on the stack of the active object ~10 in Figures 2 and 3). Effectively, this method of invocation prevents the direct interaction between a base class and data objects allocated on the stack for a derived class.
As discussed above, A prob].em arj.ses when the class library defines a base class in the hier~1:clly with a separate "task"
to perform in relation to the ~ctivàtion ongoiny in the stack outside of the invocati.oll ohai.ll, such as performing some action on a f~ll.]y corlstrllcte~ data object that is not immediately below i.t i~l tbe c]~ss lli.erarc}ly.
On completing constructioll for its separate "task", the separate T class constructor in the base class must access the active record on the stack i.n order to execute its "task". In other words, the T class constructor must be able to jump back to the originating point in the program for executing its "ta.sk".
However, as discussed ~bove, the task constructor has no record of the originating point in the program nor any return address for accessing the activation record in the ~' 20~75~2 stack. This information is contained in the constructor for the derived class called by the program from the stack.
, If the number of levels of inheritance from the T level class to the called derived class is arbitrary or unknown, and if it is further un}~nown which levels constructed on the heap define constructors and which do not (for tracing down through the invocation chain), then the T class constructor does not know where i.n the cl.ass hierarchy to look for the address o~ the originating point in the program, and is therefore unable to access the current activation record in the stack.
The solution for addre.ssing this prob].em proposed by the present invention and outlined in Figure l is to create a separate index or record in the cal].ed data object's heap allocation pointing direct].y back to the original activation record on the stack for classes in the hi.erarchy constr-icted on the heap through the invocation chain (particularly those classes haviny i.ndependellt "tasks"), and to thereby maintain a running record of the ]ocatioll for the originating point in the program on the stack, throllgll tl~e normal mechanisms invoked by stack allocat-i.otl Activation records are creat:ed on the stack through allocation. One way i.n wlli.ch t.llis normally occurs is when a data object i.s declared to be "active", that is, implemented in a operating program. Activat.i Otl records are added to the stack (the stack is said to "grow") as needed to provide sufficient short-term dynamic st-.orage space to perform the calculations and operations in i.mplementing the activation.
Stacks can grow ei.ther up or down, depending on the system specifications. In the present invention implemented in a C++ programming envi.ronment, the stack is depicted as growing up.
In the present i.nventioll and as shown in Figure 2, on first calling the derived data ohjec-t (of level A) from the activation record l.0 for the operatiny program, a single activation record 14 i.s all.ocated for a function called 2097S~2 "new" which has the purpose of making the data object's hierarchical heap construction "active".
As the invocation chain is being processed, activation records are allocated on the stack for each class constructor.
As shown in Figure 3, as the stack grows, the stack pointer 12, a register showing the beginning of the stack (the last activation record added) moves with later added activation records 14, 16, 18, 20, but the original value of the stack pointer is stored so that the original location of the stack pointer can be found when al].ocation of the stack is complete for activation purposes.
In the preferred embodiment of the invention, the class hierarchy inheriting from the T level class can be declared as an active object in order to cause the allocation of a sequence of activation records on the stack, by "overloading" (or redefining) the standard function "new" in the class with the T leve] constructor (or in any other class in the class library having a task abstraction or independent function to i.mplement). In this embodiment, objects would then have to be created and destroyed manually by the user (i.e. the cal]ing program) by allocating the objects usi.ng the C+-~ operatio~ f "new" (and deallocate them using "delete") to enforce the effect of the overloaded function.
An alternative approach would be to define a new global storage function that would automatically implement storage of the stack pointer variable in every heap allocation to be used or ignored as required by the user.
In the present application, the f~lnction will be described as "new" i.n referring eithe- to an overloading of the standard new function in C~- or to the automatic storage function.
, -~ 7 S4Z
On starting the operating program (block 30 in Figure 1), the original activation record for the operating program is allocated on the stack 32.
Referring to Figure 2, the memory stack is illustrated having the original activation record 10 allocated for the operating program and a stack pointer 12 denoting the ori~in~ting point in the program ope~tillg in the activation record 10.
According to one embodiment, the "new" function is accessed (block 34 in Figure 1) as a preparation to allocating the called data object on the heap 36.
Figure 2 illustrates the stack configuration during the execution of the "new" function. Here, the "new" function has allocated a new activation record 14 on the stack for a class construction invoked on the heap, consisting of a link record 24 and a local area 26. The "new" function has not moved the original stack pointer 10 for the operating program activation record 12, and can store the value of the stack pointer 10 in the data object's heap allocation (block 38 in Figure 1) for later use, namely accessing the return address to the original activation record of the "new"
function.
In some environments, the link record 24 may consist of only a single item, the return address for the "new" function.
On allocation of the activation record for the called class on the stack, a return from the "new"
operation is completed (block 40 in Figure 1) and storage management of the constructors in the T class hierarchy on the heap is performed in a conventional way 42. The allocation illustrated in Figure 2 is performed repeatedly as each new constructor in the hierarchy is called 44.
When constructors for the entire hierarchical chain have been called, the constructors begin their construction on the heap.
~-- --,.~ .
~097~2 Figure 3 illustrates the stack at the time that the constructor for the T level class in the hierarchy begins its construction for the T level base class block 46 in Figure 1). At this point, sequential series of activation records have been allocated on the stack from the record 14 for the called derived class to the activation record 20 allocated for the T class. The original value of the stack pointer 12 has been stored in the data object heap allocation, and is accessible through any activation record 14, 16, 18, 20 allocated on the stack by the invocation chain, although the current stack pointer 28 is at a different location.
When the T class constructor is invoked, the "new" function takes the value of the link record 30 in the activation record 20 for the T class and stores it in the constructed class on the heap to permit access to the stack directly from the T level class as soon as it is constructed on the heap.
The variable stored could be a global variable or could be in the task object area of the new]y allocated object.
The data object allocated on the heap includes a number of registers or "words". In C++ and similar technologies, the first word (register) is often reserved for other data. In such case, it is proposed in the invention to use the second word (register) or other convenient word as the stack address register consistently ln the "new" function.
On construction of the T class on the heap, the T class constructor has direct access to the stack through its link record address. Although there are now an arbitrary number of invocation records on the stack, the T level constructor can use the value for the original stack pointer 12 stored in the data object heap allocation to locate the correct originating point address, and can then use this address as the target of a jump in a new thread (blocks 48, 50 and 52 in Figure 1), or save it (blocks 48 and 50), or substitute some other address for it.
20~75~2 As an alternative to storing the stack pointer itself, the "new" function could store the actual return pointer.
However, at the time of its invocation, the return address on the stack would not be quite correct and it would be necessary to advance the returned thread past the invocation point at the constructor.
Furthermore, the constructor could take additional arguments, which would cause the compiler to insert additional instructions in the code after the invocation of the "new" function (e.g. instructions to move the arguments into the appropriate argument area). This would make it difficult to adjust the stored return pointer. It would be more appropriate for tl~e task constructor to store the stack pointer itself, since by the time the storage pointer is used, the targeted link record will contain the correct return address.
The present invention has been particularly shown and described in relation to the hardware recognized memory mechanisms and operating system implementations of the C++
programming language. ~Towever, those skilled in the art will appreciate obviolls mo~if;cations to the proposed invention for implementatioll in other compiled object-oriented language envirollments, and such modifications are intended to be covered by the appended claims.
The present invention is directed to establishing a link mechanism in run-time memory for relating object structures with the stack structure in a consistent yet optimal manner in an object-oriented computing environment.
Two major types of object-oriented language technologies have arisen since first introduction of the concept through Simula1, pure object-oriented languages such as SmallTalk2 develop~d to embrace the object-oriented approach, and compiled object-oriented languages such as C++3 that aim to optimize run-time in object-oriented technology. The present invention is directed to such compiled object-oriented language technology as C++.
Object oriented technology, in general, approaches the computer simulated modelling of real-world processes and modularization for building complex computer systems, by focusing on representing physical objects and the relationships between them, rather than on abstract procedures as in conventi,onal programming.
,~ .
The computer simulated "objects" in object-oriented technology are defined and maintairled independently of each other, the definit,;,on of an object i.ncluding its "methods"
(what procedures or operations t,he object is capable of performing) and i.ts "variables" (its attributes, the values of which can change over ti,me). This independence in definition or existence is felt to be more consistent with the way in which humans view the world, and provides a natural way of breaking down a problem to be solved, thus Simula is a modular programming language developed in the late 1960's at the Norwegian Computing Center.
SmallTalk was developed in the early 1970's at Xerox PARC (Palo Alto Research Center), California, as a complete object-oriented language.
C+~ was developed in the early 1980's at AT~T's Bell Laboratories as a 2~9754~
facilitating the construction of very complex computer systems and working models based on numerous components.
In object-oriented systems, objects are defined through class definitions. A "class" is a template that defines the methods and variables to be included in a particular type of object. Classes can be defined in terms of other classes, that is, the characteristics (methods and/or variables) of a class (a "subclass") can be "inherited" from a superior, more generalized class (a "base" class).
In addition to the methods and variables they inherit, subclas~e~ define their own methods and variables and this may include characteristics permitting the override of inherited characteristics, although the implementation of such derived classes is visible only within the class to prevent contamination of other class implementations.
An abstract class is a base class with no object members or "instances", the sole purpose of which is to organize a class hierarchy or define methods or variables that will apply to a lower level inherited class.
Since inherited methods and variables can be more narrowly defined, or even redefined in a derived class, base classes are often described as "po]ymorphic", that is, having the ability to hide different impletnentations behind a common interface, simplifying the commullicatioll among objects.
Objects defined through this technology can be highly specialized and can fit within a complex system of related, but not identical, ohjects, arld class hierarchies can encompass many levels.
In many computer systems, static storage mechanisms known as "class libraries" serve as repositories for the class hierarchy and data, and when a class is called through a preprocessor enhancement, adding object-oriented features to the already existing C language.
~0~54~
processor, channel the appropliate data to the run-time memory.
Both the C l~ngl1~ge and its object-oriented enhancement C++ (as well as other object-oriented languages) require the allocation of dynamic storage from the operating system at run-time. This run-time storage is allocated as two separate areas known as the "heap" and the "stack". Current data objects and information associated with only one activation within the compiled program are allocated to the stack for the life of the particular activation, Objects (such as classes in C++) cont~ining data that could be accessed over more than one activation must be heap allocated or static for the duration of use during run-time.
Because any data objects in a derived class declared on the stack are visible only from within the object to which the stack belongs, a problem arises where a class library defines a base class that needs to perform a task abstraction such as some action directly on an active object of a derived class beyond the first level of inheritance.
In order to implement the direct action, the base class must be able to locate and access the active object's variables declared on the stack. However, because the base class was not itself called from the stack, the only way for it to jump to the proper location in the stack is to locate the address or return address stored in the first data object called after object creation, in order to return to the origin~ting point in the executing program.
In the presence of an a-bi~l~ly number of levels of inheritance between the base class and the derived class called from the stack, the base class has no means of identifying the derived class containing the return address and directly acces.cing the location of the active data object in the stack.
One application in which this problem may arise is that of effecting concurrent threads of control discussed in my simultaneously filed Canadian patent application No. 2,097,41, entitled , .
~ ~ 9 ~ 5 4 2 "Controlling Method Invocation Sequence through Virtual Functions in an Object-Oriented Class Library".
C++ is an inherently sequential object-oriented l~n~ e without any provision for concurrent processing of independent applications or threads of control in an application. Yet as concurrency optimizes run-time, it would be a desirable feature in such a l~n~l~ge.
One approach to providing concurrency has been through the virtual class mech~ni~m, adding a special "Task" class in the class library whose function is to implement concurrent processing.
Class libraries such as Doeppner4, implement an "active object" abstraction based on a four-class "tasking" package. In these types of applications, it is the job of the Task class to spin off an independent thread of control for instances of any class for which the Task class is a base class.
When the new thread of control has been generated, the Task class directs the original thread to jump to the point in the program (called the origin~ting point) which immediately follows the invocation of the constructors, while the other thread continues executing the original task invoked in the program.
Other proposals for specific abstract "task like" classes are for directed purposes, as in U.S.
Patent No. 5,142,674 - Barker et al, relating to the use of an abstract class in an object-oriented document or local library for constructing application dependent indices to an object-oriented document database for random object retrieval.
In the example of Doeppner, the problem of the Task class not knowing where to look for the address of the Doeppner, T., Gebele, A., "C++ on a Parallel Machine", Technical Report CS-87-26, Brown University Department of Computer Science, November 1987.
f~
~as7~
ori~in~tin~; point in the program is dealt with by limiting the levels of inheritance to a known number. Similarly, in Barker, the database parameters are known from the outset.
The only other solution proposed to date to this problem is to abandon the use of a class library and to use an enhanced compiler or l~ngl1~ge extensions, as described in more detail in copending Canadian Patent Application No. 2,097,451.
It is therefore an object of the present invention to provide, in compiled object-oriented technologies such as C++ that use a standard non-extended compiler, a means for relating object structures in the heap with the stack in a consistent manner, without regard to the number of levels of class inheritance.
This is addressed in the present invention by manipulating one of the registers or variables in each object constructed on the heap to point back to an activation record in the stack. In particular, the invention provides means for storing in every base class constructed on the heap a variable directly identifying the location of an active record in the stack through which the address of the ori~in~ting point in the calling program can be accessed.
Accordingly, in one aspect, in a compiled object-oriented l~ngu~ge operating system having an operating program, a dynamic memory stack and at least one activation record allocated on the stack for the operating program, and a dynamic memory heap for allocating and subsequently constructing a data object derived from a class hierarchy called from the operating program, the present invention provides a mech~ni~m for locating the original activation record from a pre-selected base class for the data object having means for storing an index to the original activation record in the data object on allocation of the data object . ~. ; .
,?
CA9-93-008 6 ~a$75~L~
on the heap, and means for accessing the index on construction of the pre-selected base class on the heap. Preferably, the means for storing an index to the original activation record has means for locating multiple words in the data object allocated on the heap and means for storing said index in a predetermined word in the data object allocated on the heap.
According to another aspect of the invention, in a compiled C++ operating system having a program adapted to operate in the system, a memory stack adapted to allocate at least one activation record to the program for execution of an activation and a memory heap adapted to allocate storage that is static over multiple activations to a data object in a class hierarchy called in said program, a mechanism for linking data objects allocated on the heap with said at least one activation record is provided that includes means for storing an index to the at least one activation record in a data object on allocation of the data object on the heap and means for accessing the index on construction on the heap of a pre-selected base class for the data object.
Preferably, the means for storing an index comprise means for storing a stack pointer denoting an origin~ting point in the program.
The present invention also provides a method for linking a base class in a class hierarchy constructed on a memory heap with an activation record allocated on a memory stack for a program calling a derived data object in the class hierarchy and operating in a compiled object-oriented computer system. The method is the computer implemented steps of allocating the derived data object on the memory heap as a data object heap allocation, storing an index in the data object heap allocation to the activation record, and accessing the index on construction ofthe base class on the memory heap.
, 2097~42 Embodiments of the invention wil] now be described in detail in association with the accompanying drawings, in which:
Figure 1 is a flow diagram outlining the computer implemented steps in creating and accessing a linkage to the stack according to one embodiment of the invention;
Figure 2 is a schematic representation of a portion of dynamic stack memory for a processor at the start of execution of the method of the invention; and Figure 3 is a schematic representation of a portion of dynamic stack memory for a processor on construction of a base clas.3 to access the stack, according to the invention.
When an activation record on the stack issues a call to a data object in a class library in an object-oriented environment such as Cl~-, the called data object and all its superior or base classes are constructed or allocated on the heap in the following manner. Constructors in each class in the class hierarchy point to and cal]. (invoke~ the base class from whic}l the objec~. valiables for the class are derived, so that every ti.me a ~ata object is created, a series of constrl.lctors is invoked for al] classes in the class hierarchy.
In normal implementatiorls of COnstl~lCtOl~ i.nvocation in C++, suffici.ent space for the new]y allocated object, including all its levels of inheritallce in its c]ass hierarclly, is allocated OTI the ~leap, and i.ts constructor is called. This will be the constructor defined ~or the class having the deepest level of inheri.1-ance (eg., ]evel A).
C++ specifies that the class constructors for base classes be executed before derived class constructors are executed.
Thus, before its own execution, the constructor at the deepest level of inheritance (level A) will immediately call the constructor for its base class (level B) at the second deepest level of inheritance. The called base class (level B~ will in turn immediately call its own base constructor (level C), and so on, until the constructor for the highest 20975~2 , abstract class (level T) is called. Once this constructor for the highest abstract class (level T) finishes and returns, the constructor that called it (level C or higher) will perform its constructioll duties (which may involve calling constructors for member objects), and will then return to the constructor (level B) that called it. This process continues until the first constructor (level A) is allowed to do its construction. This process is referred to as the invocation chain.
The invocation chain includes the creation of a record for each base class o~ the c].ass t.hat called it to permit a return to the cal.].ing class on completion of construction of the called base c]ass. However, this inter-class record is restricted to a single leve] of inheritallce; there is no mechanism for a base class to cletermine which class in the hierarchy initiated the invocation chain and actually contains a record of the location on the stack of the active object ~10 in Figures 2 and 3). Effectively, this method of invocation prevents the direct interaction between a base class and data objects allocated on the stack for a derived class.
As discussed above, A prob].em arj.ses when the class library defines a base class in the hier~1:clly with a separate "task"
to perform in relation to the ~ctivàtion ongoiny in the stack outside of the invocati.oll ohai.ll, such as performing some action on a f~ll.]y corlstrllcte~ data object that is not immediately below i.t i~l tbe c]~ss lli.erarc}ly.
On completing constructioll for its separate "task", the separate T class constructor in the base class must access the active record on the stack i.n order to execute its "task". In other words, the T class constructor must be able to jump back to the originating point in the program for executing its "ta.sk".
However, as discussed ~bove, the task constructor has no record of the originating point in the program nor any return address for accessing the activation record in the ~' 20~75~2 stack. This information is contained in the constructor for the derived class called by the program from the stack.
, If the number of levels of inheritance from the T level class to the called derived class is arbitrary or unknown, and if it is further un}~nown which levels constructed on the heap define constructors and which do not (for tracing down through the invocation chain), then the T class constructor does not know where i.n the cl.ass hierarchy to look for the address o~ the originating point in the program, and is therefore unable to access the current activation record in the stack.
The solution for addre.ssing this prob].em proposed by the present invention and outlined in Figure l is to create a separate index or record in the cal].ed data object's heap allocation pointing direct].y back to the original activation record on the stack for classes in the hi.erarchy constr-icted on the heap through the invocation chain (particularly those classes haviny i.ndependellt "tasks"), and to thereby maintain a running record of the ]ocatioll for the originating point in the program on the stack, throllgll tl~e normal mechanisms invoked by stack allocat-i.otl Activation records are creat:ed on the stack through allocation. One way i.n wlli.ch t.llis normally occurs is when a data object i.s declared to be "active", that is, implemented in a operating program. Activat.i Otl records are added to the stack (the stack is said to "grow") as needed to provide sufficient short-term dynamic st-.orage space to perform the calculations and operations in i.mplementing the activation.
Stacks can grow ei.ther up or down, depending on the system specifications. In the present invention implemented in a C++ programming envi.ronment, the stack is depicted as growing up.
In the present i.nventioll and as shown in Figure 2, on first calling the derived data ohjec-t (of level A) from the activation record l.0 for the operatiny program, a single activation record 14 i.s all.ocated for a function called 2097S~2 "new" which has the purpose of making the data object's hierarchical heap construction "active".
As the invocation chain is being processed, activation records are allocated on the stack for each class constructor.
As shown in Figure 3, as the stack grows, the stack pointer 12, a register showing the beginning of the stack (the last activation record added) moves with later added activation records 14, 16, 18, 20, but the original value of the stack pointer is stored so that the original location of the stack pointer can be found when al].ocation of the stack is complete for activation purposes.
In the preferred embodiment of the invention, the class hierarchy inheriting from the T level class can be declared as an active object in order to cause the allocation of a sequence of activation records on the stack, by "overloading" (or redefining) the standard function "new" in the class with the T leve] constructor (or in any other class in the class library having a task abstraction or independent function to i.mplement). In this embodiment, objects would then have to be created and destroyed manually by the user (i.e. the cal]ing program) by allocating the objects usi.ng the C+-~ operatio~ f "new" (and deallocate them using "delete") to enforce the effect of the overloaded function.
An alternative approach would be to define a new global storage function that would automatically implement storage of the stack pointer variable in every heap allocation to be used or ignored as required by the user.
In the present application, the f~lnction will be described as "new" i.n referring eithe- to an overloading of the standard new function in C~- or to the automatic storage function.
, -~ 7 S4Z
On starting the operating program (block 30 in Figure 1), the original activation record for the operating program is allocated on the stack 32.
Referring to Figure 2, the memory stack is illustrated having the original activation record 10 allocated for the operating program and a stack pointer 12 denoting the ori~in~ting point in the program ope~tillg in the activation record 10.
According to one embodiment, the "new" function is accessed (block 34 in Figure 1) as a preparation to allocating the called data object on the heap 36.
Figure 2 illustrates the stack configuration during the execution of the "new" function. Here, the "new" function has allocated a new activation record 14 on the stack for a class construction invoked on the heap, consisting of a link record 24 and a local area 26. The "new" function has not moved the original stack pointer 10 for the operating program activation record 12, and can store the value of the stack pointer 10 in the data object's heap allocation (block 38 in Figure 1) for later use, namely accessing the return address to the original activation record of the "new"
function.
In some environments, the link record 24 may consist of only a single item, the return address for the "new" function.
On allocation of the activation record for the called class on the stack, a return from the "new"
operation is completed (block 40 in Figure 1) and storage management of the constructors in the T class hierarchy on the heap is performed in a conventional way 42. The allocation illustrated in Figure 2 is performed repeatedly as each new constructor in the hierarchy is called 44.
When constructors for the entire hierarchical chain have been called, the constructors begin their construction on the heap.
~-- --,.~ .
~097~2 Figure 3 illustrates the stack at the time that the constructor for the T level class in the hierarchy begins its construction for the T level base class block 46 in Figure 1). At this point, sequential series of activation records have been allocated on the stack from the record 14 for the called derived class to the activation record 20 allocated for the T class. The original value of the stack pointer 12 has been stored in the data object heap allocation, and is accessible through any activation record 14, 16, 18, 20 allocated on the stack by the invocation chain, although the current stack pointer 28 is at a different location.
When the T class constructor is invoked, the "new" function takes the value of the link record 30 in the activation record 20 for the T class and stores it in the constructed class on the heap to permit access to the stack directly from the T level class as soon as it is constructed on the heap.
The variable stored could be a global variable or could be in the task object area of the new]y allocated object.
The data object allocated on the heap includes a number of registers or "words". In C++ and similar technologies, the first word (register) is often reserved for other data. In such case, it is proposed in the invention to use the second word (register) or other convenient word as the stack address register consistently ln the "new" function.
On construction of the T class on the heap, the T class constructor has direct access to the stack through its link record address. Although there are now an arbitrary number of invocation records on the stack, the T level constructor can use the value for the original stack pointer 12 stored in the data object heap allocation to locate the correct originating point address, and can then use this address as the target of a jump in a new thread (blocks 48, 50 and 52 in Figure 1), or save it (blocks 48 and 50), or substitute some other address for it.
20~75~2 As an alternative to storing the stack pointer itself, the "new" function could store the actual return pointer.
However, at the time of its invocation, the return address on the stack would not be quite correct and it would be necessary to advance the returned thread past the invocation point at the constructor.
Furthermore, the constructor could take additional arguments, which would cause the compiler to insert additional instructions in the code after the invocation of the "new" function (e.g. instructions to move the arguments into the appropriate argument area). This would make it difficult to adjust the stored return pointer. It would be more appropriate for tl~e task constructor to store the stack pointer itself, since by the time the storage pointer is used, the targeted link record will contain the correct return address.
The present invention has been particularly shown and described in relation to the hardware recognized memory mechanisms and operating system implementations of the C++
programming language. ~Towever, those skilled in the art will appreciate obviolls mo~if;cations to the proposed invention for implementatioll in other compiled object-oriented language envirollments, and such modifications are intended to be covered by the appended claims.
Claims (11)
1. In a compiled object-oriented language operating system having an operating program, a dynamic memory stack and at least one activation record allocated on the stack for said operating program, and a dynamic memory heap for allocating and subsequently constructing a data object derived from a class hierarchy called from the operating program, a mechanism for locating the original activation record from a pre-selected base class for the data object, comprising:
means for storing an index to the original activation record in the data object on allocation of the data object on the heap; and means for accessing the index on construction of the pre-selected base class on the heap.
means for storing an index to the original activation record in the data object on allocation of the data object on the heap; and means for accessing the index on construction of the pre-selected base class on the heap.
2. A mechanism, according to Claim 1, wherein the means for storing an index to the original activation record comprises:
means for locating multiple words in the data object allocated on the heap; and means for storing said index in a predetermined word in the data object allocated on the heap.
means for locating multiple words in the data object allocated on the heap; and means for storing said index in a predetermined word in the data object allocated on the heap.
3. In a compiled C++ operating system having a program adapted to operate in said system, a memory stack adapted to allocate at least one activation record to said program for execution of an activation and a memory heap adapted to allocate storage that is static over multiple activations to a data object in a class hierarchy called in said program, a mechanism for linking data objects allocated on the heap with said at least one activation record, comprising:
means for storing an index to said at least one activation record in a data object on allocation of the data object on the heap; and means for accessing the index on construction on the heap of a pre-selected base class for the data object.
means for storing an index to said at least one activation record in a data object on allocation of the data object on the heap; and means for accessing the index on construction on the heap of a pre-selected base class for the data object.
4. A mechanism, according to Claim 3, wherein the means for storing an index comprise means for storing a stack pointer denoting an originating point in the program
5. A mechanism, according to Claim 3, wherein the means for storing an index comprises:
means for storing a return address for said program;
and means for changing said return address to point to an originating point in the program.
means for storing a return address for said program;
and means for changing said return address to point to an originating point in the program.
6. A mechanism, according to Claim 3, wherein the means for storing an index comprise:
means for locating a first word and multiple words in the data object allocated on the heap; and means for storing said index in a predetermined word higher than the first word in the data object.
means for locating a first word and multiple words in the data object allocated on the heap; and means for storing said index in a predetermined word higher than the first word in the data object.
7. A mechanism, according to Claim 6, wherein the means for storing said index in a predetermined word comprise means for storing said index in a second word located in the data object constructed on the heap.
8. A method for linking a base class in a class hierarchy constructed on a memory heap with an activation record allocated on a memory stack for a program calling a derived data object in the class hierarchy and operating in a compiled object-oriented computer system, comprising the computer implemented steps of:
allocating the derived data object on the memory heap as a data object heap allocation;
storing an index in the data object heap allocation to the activation record; and accessing the index on construction of the base class on the memory heap.
allocating the derived data object on the memory heap as a data object heap allocation;
storing an index in the data object heap allocation to the activation record; and accessing the index on construction of the base class on the memory heap.
9. A method, according to Claim 8, wherein the step of storing the index comprises:
locating a stack pointer for the activation record on allocation of the data object on the memory heap; and storing said stack pointer as a variable in the data object heap allocation.
locating a stack pointer for the activation record on allocation of the data object on the memory heap; and storing said stack pointer as a variable in the data object heap allocation.
10. A method, according to Claim 8, wherein the step of storing the index comprises:
locating a return address for the program; and storing the return address as a variable in the data object heap allocation, and, on accessing the index on construction of the base class on the memory heap, the method further comprising the step of:
altering the return address to return to a selected point in the program after constructing the derived data object.
locating a return address for the program; and storing the return address as a variable in the data object heap allocation, and, on accessing the index on construction of the base class on the memory heap, the method further comprising the step of:
altering the return address to return to a selected point in the program after constructing the derived data object.
11. A method, according to Claim 8, further comprising the step of locating multiple words in the data object heap allocation, and wherein the step of storing the index comprises storing the index in a pre-determined word in the data object heap allocation.
,, .
,, .
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002097542A CA2097542C (en) | 1993-06-01 | 1993-06-01 | Linkage for accessing data objects in the stack |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002097542A CA2097542C (en) | 1993-06-01 | 1993-06-01 | Linkage for accessing data objects in the stack |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2097542A1 CA2097542A1 (en) | 1994-12-02 |
| CA2097542C true CA2097542C (en) | 1998-09-01 |
Family
ID=4151734
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002097542A Expired - Fee Related CA2097542C (en) | 1993-06-01 | 1993-06-01 | Linkage for accessing data objects in the stack |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2097542C (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6052778A (en) * | 1997-01-13 | 2000-04-18 | International Business Machines Corporation | Embedded system having dynamically linked dynamic loader and method for linking dynamic loader shared libraries and application programs |
| US6363436B1 (en) | 1997-01-27 | 2002-03-26 | International Business Machines Corporation | Method and system for loading libraries into embedded systems |
| US6934939B2 (en) | 2001-02-28 | 2005-08-23 | International Business Machines Corporation | Method for unwinding a program call stack |
-
1993
- 1993-06-01 CA CA002097542A patent/CA2097542C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2097542A1 (en) | 1994-12-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5632034A (en) | Controlling method invocation sequence through virtual functions in an object-oriented class library | |
| CA2115464C (en) | Concurrent processing in object oriented parallel and near parallel systems | |
| US7047524B1 (en) | Object oriented ADN and method of converting a non-object oriented computer language to an object oriented computer language | |
| US5848419A (en) | Methods and apparatus for providing transparent persistence in a distributed object operating environment | |
| JP3550151B2 (en) | Load linking apparatus and method | |
| US6119145A (en) | Multithreaded client application storing a separate context for each transaction thus allowing threads to resume transactions started by other client threads | |
| US5414854A (en) | Object-oriental system for managing shared libraries | |
| Gorlen | An object‐oriented class library for C++ programs | |
| US6526457B1 (en) | Systems utility object interface for facilitating software portability | |
| EP0620520A1 (en) | Method for making persistent data objects having hidden pointers | |
| US8997042B2 (en) | Flexible and run-time-modifiable inclusion of functionality in computer code | |
| JPH0687222B2 (en) | Intercommunication system and method between application and database management system | |
| CN110362301B (en) | Processing method for terminal application behavior reflection | |
| US5062039A (en) | Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces | |
| Pollack et al. | Supporting Ada memory management in the iAPX-432 | |
| Jagannathan et al. | A customizable substrate for concurrent languages | |
| CA2097542C (en) | Linkage for accessing data objects in the stack | |
| JP4084956B2 (en) | Object collection method and system | |
| Bündgen et al. | A fine-grained parallel completion procedure | |
| CA2115463C (en) | Mechanism and method for allocating active objects on a processor stack | |
| CN110347448B (en) | Method for constructing runtime model of terminal application behavior | |
| Gwinn | Object-oriented programs in realtime | |
| Zdonik | Why properties are objects or some refinements of “is-a” | |
| CA2097541C (en) | Concurrency control through a class library in object oriented technology | |
| Rios et al. | Patterns for safety-critical Java memory usage |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |