WO2017095367A1

WO2017095367A1 - Managing objects stored in memory

Info

Publication number: WO2017095367A1
Application number: PCT/US2015/062931
Authority: WO
Inventors: Evan R. Kirshenbaum
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-11-30
Filing date: 2015-11-30
Publication date: 2017-06-08

Abstract

In one example in accordance with the present disclosure, a method may include receiving a first pointer to an object and ensuring that a stored pointer to the object exists in a reference table. The method may also include obtaining a shared pointer to the object, the shared pointer having an associated reference count and modifying the reference count to indicate a number of a number of copies of the shared pointer within a computer system. The method may also include determining that the reference count indicates that there are no remaining copies of the shared pointer in the computer system and removing the stored pointer from the reference table upon making the determination.

Description

MANAGING OBJECTS STORED IN MEMORY

BACKGROUND

[0001] Garbage collection Is a type of memory management where a garbage collector reclaims memory occupied by objects that are no longer in use. Garbage collection may be used and/or required by certain programming languages.

Although garbage collection may provide significant benefits, garbage collection may require some system overhead and thus may Impact performance.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein;

[0003] FIG. 1 is a block diagram of an example computing environment in which managing objects stored In memory may be useful;

[0004] FIG. 2 is a flowchart of an example method for obtaining a shared pointer to the object referred to by the first pointer;

[0005] FIG. 3 is a flowchart of an example method for identifying pointers In a cache;

[0008] FIG. 4 is a flowchart of an example method for managing objects stored in memory;

[0007] FIG. 5 is a block diagram of an example system for managing objects stored in memory; and

[0008] FIG. 8 is a block diagram of an example system for managing objects stored in memory.

DETAILED DESCRIPTION

[0009] The data accessed within a computer system may comprise a set of objects (also known as records, structures, Instances, or simply data values) stored in the memory or storage of the computer system. Access to objects may be by use of pointers (or references or links) that contain sufficient information to Identify the object they refer to. This information may Include an address of the object, an offset of a common base address, a key that can be looked up in a table, or other information. These pointers may be stored within processor registers, on a program stack, in global variables, within objects., and elsewhere, in a system that employs garbage collection (GC), some objects may be allocated on a heap managed by a garbage collector. When an object is allocated, unused space Is identified on the heap, and the object Is created In that space. The job of the garbage collector Is to distinguish between allocated objects that are reachable and those that are unreachable, where an object is reachable if and only if it is possible for any program code to make reference to the object. When objects are determined to be unreachable, the garbage collector declares the space they occupy to be unallocated and returns the memory to the allocator for use In allocating new objects,

[0010] At the beginning of a GC cycle, a garbage collector may determine all of the root pointers for each process that is using the heap. A root pointer is a pointer to an object stored in a garbage-collected heap where the root pointer Itself is observed by a garbage collector in a location other than on the garbage-collected heap. For example, the pointer may be observed in a processor register, on a program or thread stack, In a global or thread-local variable or structure, or on a heap other than the garbage-collected heap).

[0011] The objects pointed to by the roof pointers are considered reachable, as are ail objects pointed to by GC pointers contained within reachable objects. Any part of the GC-managed heap that is not reachable may be considered garbage and used in future object allocation. Root pointers to objects on GC heap can be found on a thread's local stack. To find root pointers on the thread's local stack, the threads may be scanned and root pointers may be Identified. There are, however, numerous other places where root pointers to objects on the GC heap can be found, such as In global variables, class-static variables, function-static variables, objects created on the process's local heap, etc. The system for managing objects provides a centralized way to manage and update values of root pointers that exists on a shared heap.

[0012] Example systems for managing objects stored in memory discussed herein manage storage using reference counting. A number, referred to as a reference count, may be used to indicate a number of pointers to an object. A pointer reflected in an object's reference count may be called reference counted (or counting) pointers (or references) or shared pointers (or references). One example shared pointer that may be used is the standard C÷+ shared_ptr<T> class, which implements β shared pointer to objects of 8 type T. When snored pointers ere copied or assigned, the resulting pointer may be associated with the same reference count and that count is incremented. When shared pointers are destroyed or overwnnsn oy an assignment, me assocMneo reverence couni is oecrerneniea. A reference count being decremented to zero is indteafive of there befeig no further shared pointers referring to the object arid the oojectrnay be deleted atxJ its spece made avaflabie for future object alocatton.

[0013] The reference count may be maintained in a separate object catted a control block. The Mstime of a control block may be independent of the 1Mb vie of the object, and the reference counting pointer may contain the address (or equivalent location information) of both the object and the control block associated with the object Example systems tor managing objects stored in memory discussed herein may also contain weak reference counted (or counting) pointers (or references), also known as weak pointers (or references). One example of a weak pointer that may be used is the standard C++ weak_ptr<T> class. Weak pointers may refer to an object and an associated reference count (or control block), but the existence of weak pointers is not refected to the associated reference count Thus weak pointers can continue to exist even when their associated reference counts are zero. A shared pointer may be made based on a weak pointer. This shared pointer may refer to the same object the week pointer referred if the weak pointer referred to an object (e.g., was not a nufl pointer) and Hs associated reference count was not zero before toe creation of the shared pointer. Otherwise, the shared pointer wH be a nul pointer. To manage the Nfetbiie of the control block object toe control block may contain a separate counter roltocttog the number of weak pointers associated with ine control DOCK, ine control rxocK may aiso contain iiruiiiiauon {e.g., oam ana references to machine tostructJons) sufficient to delete the object and make Hs apace avnflablci for future aMocatton.

[0014] Example systems for managing objects stored in memory may remove a stored pointer corresponding to the object from a reference table when the reference count has reached zero, as opposed to eutomeocaMy deleting the object pointed to by the stored pointer. A stored pointer is a pokiter in a reference table used to manage shared pointers. Accordtogty, rnuWpte shared pointers can point to the same object and eech shared pointer may have its own reference count Because Hie object is not doletod when the reference counter reecho zero, the shared pointer correspondbig to the reference counter that reeched zero is removed from the reference table wHhout effecting the underlying object or any other shared pointers that point to the object. An example method may include may todude receiving a first pointer to an object and ensuring that a stored pointer to the object exists in a reference table. The method may also include obtaining a shared pointer to toe object, toe shared pointer having an associated reference count aiKi modifying the reference count to indicate a number of a number of copies of the snared pointer within a computer system. The method may also include determtofeig that the reference count toojcaies nat mere are no remaining copies oitnesnarea poinierin the computer system and removing the stored pototer from the reference table upon making the dotemtinetion.

[0015] FIG. 1 is a block dagrem of an example system 100 tor managing objects stored in memory of e computer system. System 100 may include e processor 102 and a memory 104 that may be coupled to each other through convnunicafion link (e.g., a bus). Processor 102 may include a Central Processing Unit (CPU) or another suitable processor. In some examples, memory 104 stores machine readable tasfcucMons executed by processor 102 Ibr system 100. Memory 104 may Include any suitable cornbination of volatile and/br non-voiatie memory, such as combinations of Random Access Memory (RAM), Read-Only Memory (ROM), flash memory, end/or other suitable memory.

[0016] Memory 104 stores instructions to be executed by processor 102 inducing insfrLK^ons 1b† a pointer receiver 112, e p 114, a pointer obtainer 116, a reference count modeler 118, a reference count hanoTer 120, a pointer remover 122, a cacne rananr 1Z4, a poeinr eriumereior 120, anorar otner components. Accorangto various implementations, system 100 for managing objects may be (n^tementod in hardware and/br a combination of hardware and prograrrna^tta

runnermore, n rKi. 1 ana otner Figures cescriDSfl neretn, anereni numoers or components or entffies tJtan depicted may be used.

[0017] Processor 102 may execute Swfrudkxttofpofr^recehw 112 to receive a first pointer to an object. The first pointer may be, for example, a garbage collection pointer. The garbage collection pointer may be an instance of a GC pointer type (e.g., a class of an object oriented language). The garbage collection pointer may represent a pointer to an object of type T that exists on a shared heap managed by the garbage collector. The heap may be contained within a non-volatile memory.

[0018] Processor 102 may execute instructions of pointer ensurer 114 to ensure that a stored pointer to the object exists in a reference table. A stored pointer is a pointer in a reference table used to manage shared: pointers (e.g. as discussed below in reference to pointer obtainer 116}. A stored pointer may be created for each non- stack reference to a GC managed object. When a garbage collection pointer is created, a corresponding stored pointer may be created, including an associated shared pointer, and the stored pointer may be put in the reference table.

[0019] Pointer ensurer 114 may identify a slot in toe reference table as an unused slot and remove the slot from a list of unused slots. Pointer ensurer 1 14 may further construe! the stored pointer based on the first pointer and store toe stored pointer in the slot in the reference table.

[0020] The reference table may be used to manage the root pointers for a process. For example, the reference table may be an array of garbage collection pointers that holds root pointers pointing to objects stored in the GC managed heap, where the objects are reachable by code running in the process via references other than those on the stack of any of the threads of the process. The reference table may be a multi-level table. For example, the reference table may be implemented as a two-level array comprising a fixed-size array of pointers to lazily-constructed fixed size arrays of slots. The upper array may be referred to as the spine and the lower arrays may be referred to as blocks. One example reference table contains block each containing 10,000 slots and a spine containing 100.000 block pointers, allowing for a maximum of one billion active root pointers. This example reference fable Is only an example and other reference tables may have different numbers of spines, blocks and root pointers. A slot may contain a root pointer. When a slot is an empty slot (e g., it contains a null pointer rather than a root pointer), if may contain an Index or other Indication of another empty siot or an indication that It does not refer to another empty slot. In toss way, the reference table may contain one or more free lists of empty slots. The reference table may also be associated with an indication of the slot with the greatest index that has ever been claimed to receive a roof pointer.

[0021] Processor 102 may execute Instructions of pointer obtainer 116 to obtain a shared pointer to the object. The shared pointer may have an associated reference count (e.g., located: within a control block object pointed to by the shared pointer and by all copies of the shared pointer). Processor 102 may execute Instructions of reference count modifier 118 to modify the reference count to indicate a copies of the shared pointer within the computer system. The copies of the shared pointer may include the shared pointer Itself, each copy of the shared pointer, copies of the copies, etc. As the shared pointer and Its copies are copied or destroyed, the reference count may he incremented: and decremented. Processor 102 may execute Instructions of reference count handler 120 to determine that the reference count indicates that there are no remaining copies of the shared pointer in the computer system. The reference count may also be associated (e.g., in the control block) with information sufficient to locate the stored pointer in the reference table, information sufficient to locate the stored pointer In the reference table may be an Index into the reference table, an address or other location, a pointer to the address or other location, etc.

[0022] Processor 102 may execute Instructions of pointer remover 122 to remove the pointer from the reference table when the last copy of the shared pointer is destroyed or assigned a different value (i.e., the reference count becomes zero). Pointer remover 122 may remove the pointer from the reference table by identifying the slot containing the pointer by using information associated (e.g., in the control block) and replacing the pointer in the slot with a null pointer. Pointer remover 122 may also add the now-empty slot to a free list of empty slots (e.g., the free list associated with the current thread s thread-local cache, as described below, In regards to Fig. 3). Adding the slot to the free list may comprise copying the indication of the head of the free list Info the slot as the next empty slot and setting the head of the free list to refer to the slot.

[0023] Processor 102 may execute Instructions of cache handler 124 to determine whether a cache contains a second pointer to the object. This is explained in further detail below, In regards to Fig. 3. When a shared pointer Is created from the first pointer, the system may determine if a pointer associated with the first pointer, such as, for example, a copy of the first pointer, already exists in the reference table by checking for pointers referring to the object referred to by the first pointer In a cache. As will be discussed In further detail below in regards to Fig. 3, the cache may include a thread-local cache and/or a global cache, in this manner, the system may prevent duplicate entries to be entered in the reference table.

[0024] Processor 102 may execute instructions of pointer enumerator 126 to enumerate pointers in the reference table. Pointer enumerator 126 may enumerate each pointer in the reference table. Each object pointed to by an enumerated pointer may be considered to be a live object by a garbage collector managing the heap.

[0025] FIG.2 is a flowchart of an example method 200 for obtaining a shared pointer to the object referred to by the first pointer. Method 200 may be described below as being executed or performed by a system, for example, system 100 of FIG. 1 , system 500 of FIG. 5 or system 600 of FIG. 8, Other suitable systems and/or computing devices may be used as well. Method 200 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. Alternatively or in addition, method 200 may be implemented in the form of electronic circuitry (e.g., hardware). The steps of method 200 may be executed substantially concurrently or in a different order than shown in FIG. 2. Method 200 may include more or less steps than are shown in FIG. 2. The steps of method 200 may, at certain times, be ongoing and/or may repeat.

[0028] Method 200 may start at step 202 and continue to step 204, where the method may include Identifying an empty slot in the reference table. As discussed above, the reference table may be used to manage a set of root pointers. Identifying an empty slot may Include identifying a slot as the head of a free list of empty slots (e.g. , the free list associated with the current thread's thread-local cache, as described below with regard to Fig. 3). If the free list is empty, Identifying an empty slot may further include first obtaining a new free list (e.g., from the collection of free lists associated with the global cache, as described below with regard to Fig. 3, or obtaining a never-before used slot from the reference table). At step 206, the method may include claiming the empty slot In the reference fable to prevent the slot from being subsequently identified as an empty slot before it is cleared. Claiming the empty slot may Involve removing the slot from the free list of empty slots, as by replacing the head of tie free list by the next empty slot indicator associated with the slot. Alternatively, claiming the empty slot may Involve setting an indicator (e.g., a bit or Hag) associated with the slot. At step 208, the method may include installing a stored pointer (e.g. a GC pointer) into the empty slot. The stored pointer may point to the object pointed to by the first pointer and at step 210, the method may include creating a shared pointer. The shared pointer may correspond to the first pointer. The shared pointer may point !o the same object that the first pointer points to. When the las! copy of the shared pointer is destroyed, the stored pointer may be removed from the table. For example, the shared pointer may be associated (e.g., in the control block) with a deleter object that stores the index of the slot and which, when called when the reference count associated with the shared pointer reaches zero, clears the slot (e.g., by overwriting the stored pointer by a null pointer).

[0027] FIG. 3 is a flowchart of an example method 300 for identifying pointers in a cache. Method 30Q may be described below as being executed or performed by a system, for example, system 100 of FIG. 1 , system 500 of FIG. 5 or system 800 of FIG. 8. Other suitable systems and/or computing devices may be used as well. Method 300 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. Alternatively or in addition, method 300 may be implemented in the form of electronic circuitry (e.g., hardware). The steps of method 300 may be executed substantially concurrently or in a different order than shown In FIG. 3. Method 300 may include more or less steps than are shown in FIG. 3. The steps of method 300 may, at certain times, be ongoing and/or may repeat.

[0028] Method 300 may start at step 302 and continue to step 304, where the method: may include determining if a cache contains a second pointer to the object. The second pointer may be a weak pointer or any form of pointer based on which a shared pointer may be created.

[0029] Determining whether the cache contains the second pointer to the object may also include obtaining a weak pointer associated with the first pointer. The weak pointer may be In the cache. The method may also include obtaining a third pointer based on the weak pointer and determining whether the third pointer points to the object. The third pointer may be a shared pointer or any pointer which can be constructed from a weak pointer. Upon determining that the third pointer points to the object, the method may Include identifying the weak pointer as the second pointer or otherwise computing the second pointer based on the weak pointer., including computing the second pointer based on the third pointer. [0030] If the cache does contain the second pointer, (YES branch of step 304), the method 300 may continue to step 306, where method 300 may Include inferring, based on the second pointer being in the cache, that the reference table contains the stored pointer. In other words, if the second pointer is in the cache, it can be inferred that the reference table contains the stored pointer, without checking the reference table itself,

[0031] As discussed above, a shared pointer to the object, with an associated reference count, may be obtained. At step 308, the method may include computing the shared pointer based on the second pointer. For example, the method may include identifying the third pointer as the shared pointer, and the third pointer may be computed based on the weak pointer Identified with the second pointer. Method 300 may eventually continue to step 310, where method 300 may stop.

[0032] If the cache does not contain a second pointer to the object, (NO branch of step 304), the method 300 may continue to step 312, where method 300 may include obtaining the stored pointer based on the first pointer (e.g., by creating the stored pointer to point to the object referred to by the first pointer). At step 314, the method may include inserting the stored pointer in the reference table. At step 316, the method may include obtaining the shared pointer based on the first pointer (e.g., by creating the shared pointer to point to the object referred to by the first pointer). Obtaining the shared pointer based on the first pointer may comprise creating a new control block, different from all other control blocks in the system, and associating it with the shared pointer. At step 318, the method may include obtaining the second pointer based on the first pointer. The second pointer may be obtained, for example, by creating a weak pointer copy of the shared pointer, which is obtained based on the first pointer. At step 320 the method may Include adding the second pointer to the cache. Method 300 may eventually continue to step 310, where method 300 may stop.

[0033] The cache may comprise two levels and may include a thread-local cache and a global cache. A thread local cache may be created for each program thread using the GC managed heap and may only be accessed by the program thread It was created for. The thread local cache may be created on demand. The thread-local cache may also include an immutable reference to the process's reference fable, an immutable reference to the global cache, a fixed-sized array of weak references and an integer or other indication of a first empty slot of the reference table in a free list of empty slots. [0034] The global cache may be associated with a plurality of threads using the GC managed heap. There may be a single global cache per operating system process containing threads using the GG managed heap. The global cache may include a fixed size array of entries, each of which contains a weak reference and a flag. The flag may he used to ensure ihai only one thread at a time is accessing an entry in the reference table. An example flag that may be used is an atomicjag supported by the C++ programming language. The atomic _fiag in C++ Is an object that supports the dear[ } and the test_and__set (/operations. The dear( } operation atomieaiiy sets the atomic flag to false and the test_and_set( ) operation atomieally sets the flag to true and returns the prior value. If the test_and_set{ } operation on a given atornicjlag object returns a false value, this indicates that the invoking thread was the first to Invoke the operation on the object or the first to do so after the c!ear( ) operation was invoked on the object. The global cache may further include a collection of free lists of empty slots (e.g., indications of the first slots of such free lists). When thread-local caches are destroyed (e.g., upon thread exit), their associated free lists, when nonempty, may be added to the global cache's collection of free lists.

[0035] When converting the garbage collector pointer (e.g., the first pointer) to the shared pointer, a lookup operation may be performed by a local cache handler In the thread-local cache of the thread. The lookup operation may accept the garbage collector pointer as an argument and return the shared pointer. If the value of garbage collector pointer is null a null shared pointer may be returned, if the value of the garbage collector pointer Is not null, the local cache handler may obtain a bare pointer (e.g., a C++ T* pointer) to the object the GC pointer points to. The local cache handier may then determine the index Into the array corresponding to the hare pointer. The index may be determined by converting the bare pointer to a number, performing shift operations on the number to remove any low-order bits known to be zero due to the in-memory alignment of the object pointed to, and taking the modulus of the resulting number with the array size. In example Implementations in which the thread-local cache's array size is constrained to be a power of two, this modulus may be performed by means of a bitwise AND operation using the appropriate bit mask. The weak pointer contained at the index In the thread-local-cache's weak pointer array may converted to a shared pointer (e.g., by the C++

weak__ptr<T>::loc./cf^') function). [0036] If the value of the resulting shared pointer is null., the array slot may be empty or It may contain a weak pointer to an object where the last shared pointer associated with the weak pointer's reference count was destroyed. If the value of the shared pointer is not equal to the bare pointer (e.g., if It is null or if points to a different object than does the garbage collector pointer), then it can be determined that the thread-local cache does not contain a weak pointer referring to the correct object, since there is only one Index thai such a weak pointer could reside at. In this scenario, the local cache handler may request the global cache handier to perform a lookup operation In the global cache based on the bare pointer. Specifically, the method 300 may include determining that the thread-local cache does not contain a second pointer (i.e. as discussed above in regards to step 304} and determining that the global cache contains the second pointer. The method may further Include adding a value based on the second pointer to the thread-local cache.

[0037] The lookup operation performed by the global cache handler will be discussed in further detail below. The global cache handler may return the result of the lookup operation to the local cache handler as a shared pointer. If the shared pointer received from the global cache handler matches the bare pointer, the local cache handier may put a weak pointer copy of the shared pointer in the thread-local cache's weak pointer array at the index previously computed. The local cache handler may return the shared pointer, which may be either the shared pointer found during the thread-local cache lookup operation or the shared pointer received from the global cache, as the result of the lookup operation. The weak pointers in the thread-local cache and global cache may refer to objects as being of a common type, which may be a base type in a hierarchy of types In some examples, when the type of object referred to by the garbage collector type passed in as an argument to the thread-local lookup operation differs from that of the shared pointer determined by the local cache handler, the local cache handler may cast the shared pointer to the appropriate shared pointer type (e.g., corresponding to the GC pointer type) and return the resulting shared pointer.

[0038] A lookup operation may be also be performed in the global cache by a global cache handler. The global cache's lookup method takes a (bare) pointer to the object as a parameter and a creation function and returns a shared pointer to the object. The creation function may create a stored pointer based on a GC pointer (e.g., the GC pointer known to the local cache handier) and insert It into the reference table. The creation function may further create a shared pointer pointing to the same object as the GC pointer and associated with a new control block not associated with any other shared pointer. The creation function may return the created: shared pointer. The global cache handler may determine (e.g., by means similar to those used by the local cache handier to determine an index) the index into the global cache's array corresponding to the pointer, where the index uniquely identifies an entry in the global cache's array. The global cache handler may then request an exclusive access to the identified entry by attempting to set the entry's flag. For example, the global cache handler may invoke the test_and_set( } operation on the atomicjiag corresponding to the entry. An exclusive access means that no entity other than the entity with exclusive access can access the entry. In other words, if the global cache handler has exclusive access to the identified entry, no other entity can access the identified entry. An exclusive may be useful in preventing other entitles (i.e. other processes, threads, etc, from accessing the entry during the lookup operation. If the result of this operation is a true value, Indicating that the flag was set prior to the invocation, the global cache handler may infer that a global cache handler operating In another thread has acquired exclusive access to the entry, if the result of the operation is false, then the Invocation changed the flag from unset to set, and the global cache handier operating in this thread has acquired exclusive access to the entry.

[0039] if exclusive access has not been acquired, the global cache handier may infer that another thread is currently using the entry and that it is therefore unsafe for this thread to do so. In this situation, the global cache handler may invoke the creation function and return the resulting shared pointer. As a side-effect of Invoking the creation function, a stored pointer may be created and added to the reference table. If exclusive access has not been acquired, the global cache handler may return from the lookup operation without clearing the entry's flag. If exclusive access to the entry has been acquired, the global cache handier may obtain a shared pointer based on the weak pointer contained in the entry (e.g., by means of the C++ weak__ptr<T>;jock(} method). If the resulting shared pointer refers to the same object as the pointer parameter, then the global cache contains a pointer (i.e., the weak pointer) to the object, and the global cache handler may relinquish its exclusive access to the entry (e.g., by calling the clearQ method on the entry's flag) and return the shared pointer, if the resulting shared pointer does not refer to the same object as the pointer parameter, then the global cache handler may call the creation function to create a new shared pointer referring to the object. As a side-effect of invoking the creation function, a stored pointer may be created and added to the reference table. The global cache handler may create a weak pointer based on the shared pointer and may store the weak pointer in the entry. It may then relinquish its exclusive access to the entry and return the shared pointer. Specifically, the method 300 may include identifying an entry In the global cache associated with the first pointer, requesting an exclusive access to the entry; obtaining a weak pointer associated with the entry and relinquishing the exclusive access

[0040] FIG. 4 is a flowchart of an example method 400 for managing objects stored in the memory of a computer system. Method 400 may he described below as being executed or performed by a system, for example, system 100 of FIG. 1 , system 500 of FIG. 5 or system 600 of FIG. 6. Other suitable systems and/or computing devices may be used as well. Method 400 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. Alternatively or In addition, method 400 may be implemented In the form of electronic circuitry (e.g., hardware). In alternate examples of the present disclosure, at least one step of method 400 may be executed substantially concurrently or in a different order than shown in FIG. 4, In alternate examples of the present disclosure, method 400 may include more or less steps than are shown in FIG. 4. In some examples, at least one of the steps of method 400 may, at certain times, be ongoing and/or may repeat.

[004] ] Method 400 may start at step 402 and continue to step 404, where the method may Include receiving a first pointer to an object.. The first pointer may be, for example, a garbage collection pointer. The garbage collection pointer may belong to a class of an object oriented language. The object may be stored in a GO managed heap. At step 406, the method may include ensuring that a stored pointer to the object exists in a reference table.. The reference table may be a multi-level table. Ensuring that the stored pointer to the object exists In a reference table may further include identifying a slot in the reference table as an unused slot, claiming the slot, constructing the stored pointer based on the first pointer and storing the stored pointer in the slot. At step 408, the method may include obtaining a shared pointer to the object. The shared pointer may have an associated reference count. The reference count may be associated with information sufficient to locate the stored pointer in the reference table. At step 410, the method may include modifying the reference count to indicate a number of copies of the shared pointer within a computer system. The number of instances may include the shared pointer and each copy of the shared pointer. At step 412, the method may include determining that the reference count indicates that there are no remaining copies of the shared pointer in the computer system. At step 414, the method may include removing the stored pointer from the reference table. Step 414 may be performed upon making the determination in step 412.

[0042] FIG. 5 is a block diagram illustrating one example of a processing system 500 for implementing the system 500 for managing objects stored in the memory of a computer system. System 5Q0 may include a processor 502 and a memory 5Q4 that may be coupled to each other through a communication link (e.g., a bus). Processor 502 may include a Central Processing Unit (CPU) or another suitable processor, in some examples, memory 504 stores machine readable instructions executed by processor 502 for system 500. Memory 504 may include any suitable combination of volatile and/or non-volatile memory, such as combinations of Random Access Memory (RAM), Read-Only Memory (ROM), flash memory; and/or other suitable memory.

[0043] Memory 504 stores instructions to be executed by processor 5Q2 Including instructions for a pointer receiver 510, cache handler 512, pointer creator 514, reference count modifier 516 and pointer remover 518. The components of system 500 may be implemented in the form of executable instructions stored on at least one machine- readable storage medium of system 500 and executed by at least one processor of system 500. Alternatively or in addition, each of the components of system 500 may be implemented: in the form of at least one hardware device Including electronic circuitry for implementing the functionality of the component.

[0044] Processor 502 may execute Instructions of pointer receiver 502 to receive a first pointer to an object. The first pointer may be, for example, a garbage collection pointer. The garbage collection pointer may belong to a class of an object oriented language. The object may be stored In a GC managed heap. Processor 502 may execute instructions of cache handler 504 to determine that a cache does not contain a second pointer to the object. The cache may include a thread-local cache associated with a thread within the computer system and a global cache associated with a plurality of threads within the computer system. The plurality of threads may include the thread. Processor 502 may execute instructions of pointer creator 506 to create a stored pointer and a shared pointer corresponding to first pointer. The shared pointer may have an associated reference count. The reference count may be associated with information sufficient to locate the stored pointer in the reference table. Processor 502 may execute instructions of reference count modifier 508 to modify the reference count to indicate a number of instances of the shared pointer within the computer system. The n umber of instances may Include the shared pointer and each copy of the shared pointer. Processor 502 may execute instructions of pointer remover 510 to remove the stored pointer from a reference table when the reference count indicates that there are no remaining instances of the shared pointer In the computer system. The reference tabie may be a muiti-ievei table.

[0045] FIG. 6 is a block diagram of an example system 800 for managing objects stored in the memory of a computer system. System 800 may be similar to system 100 of FIG. 1, for example, in the example illustrated in FIG. 5, system 600 includes a processor 602 and a machine-readable storage medium 804. Although the following descriptions refer to a single processor and a single machine-readable storage medium, the descriptions may also apply to a system with multiple processors and multiple machine-readable storage mediums. In such examples, the instructions may be distributed (e.g., stored) across multiple machine-readable storage mediums and the instructions may be distributed (e.g., executed by) across multiple processors.

[0046] Processor 802 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored In machine-readable storage medium 804. in the example illustrated in FIG. 6, processor 602 may fetch, decode, and execute instructions 606, 608, 610, 612, 614, 816 and 618 for managing objects stored in the memory of a computer system. As an alternative or in addition to retrieving and executing instructions, processor 602 may Include one or more electronic circuits comprising a number of electronic components for performing the functionality of at least one of the instructions In machine- readable storage medium 804. With respect to the executable insfruction representations (e.g., boxes) described and shown herein, It should be understood that part or all of the executable instructions and/or electronic circuits included within one box may, in alternate examples., be inducted in a different box shown in the figures or in a different box not shown .

[0047] Machine-readable storage medium 604 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 804 may be, for example. Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. Machine-readable storage medium 804 may be disposed within system 800, as shown in FIG. 6. In this situation, the executable instructions may be installed" on the system 800. Alternatively, machine-readable storage medium 604 may be a portable, external or remote storage medium, for example, that allows system 600 to download the instructions from the portabie/external/remote storage medium. In this situation, the executable Instructions may be part of an 'installation package". As described herein, machine-readable storage medium 804 may be encoded with executable Instructions for using pointers In a memory managed system.

[0048] Referring to FIG. 6, pointer receive instructions 806, when executed by a processor (e.g., 602), may cause system 600 to receive a first pointer. The first pointer may correspond to an object. The object may be stored in a GC managed heap. The first pointer may be, for example, a garbage collection pointer. The garbage collection pointer may belong to a class of an object oriented language. The reference table may be a multi-level table. Local cache instructions 608, when executed by a processor (e.g., 602), may cause system 600 to determine that no pointer corresponding to the first pointer exists in a local cache. The local cache may correspond to a thread using the first pointer. Global cache instructions 610, when executed by a processor (e.g., 802), may cause system 600 to determine that a second pointer corresponding to the first pointer exists in a global cache. The global cache may correspond to a plurality of threads including the first thread sharing a centrally managed data store.

[0049] Pointer create instructions 612, when executed by a processor (e.g., 602), may cause system 800 to create a stored pointer and a shared pointer corresponding to the first pointer, the shared pointer having a reference count. The shared pointer may have a reference count. The reference count may be associated with information sufficient to locate the stored pointer in a reference table. Pointer add instructions 614, when executed by a processor (e.g., 602), may cause system 800 to add the stored pointer to a reference table. Reference count modify instructions 616, when executed by a processor (e.g., 802), may cause system 600 to modify the reference count to indicate a number of instances of the shared pointer within the computer system. The number of instances may include the shared pointer and each copy of the shared pointer. Pointer remove instructions 618, when executed by a processor (e.g., 602), may cause system 600 to remove the stored pointer from the reference table when the reference count Indicates that there are no remaining instances of the shared pointer in the computer system.

[0G5GJ The foregoing disclosure describes a number of examples for managing objects stored in the memory of a computer system. The disclosed examples may include systems, devices, computer-readable storage media, and methods for using pointers In a memory managed system. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1-6. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. Further, all or part of the functionality of illustrated elements may co-exist or be distributed: among several geographically dispersed locations. Further, the disclosed examples may be implemented in various environments and are not limited to the Illustrated examples.

[0051] Further, the sequence of operations described In connection with FIGS. 1-6 are examples and are not Intended to be limiting. Additional or fewer operations or combinations of operations may be used or may vary without departing from the scope of the disclosed examples. Furthermore, Implementations consistent with the disclosed examples need not perform the sequence of operations in any particular order. Thus, the present disclosure merely sets forth possible examples of implementations, and many variations and modifications may be made to the described examples.

Claims

1. A method com prisi ng :

receiving a first pointer to an object;

ensuring that a stored pointer to the object exists in a reference table;

obtaining a shared pointer to the object, the shared pointer having an associated reference count;

modifying the reference count to indicate a number of copies of the shared pointer within a computer system;

determining that the reference count indicates that there are no remaining copies of the shared pointer in the computer system; and

removing the stored pointer from the reference table upon making the determination.

2. The method of claim 1 , further comprising:

enumerating each pointer in the reference table, wherein each object pointed to by an enumerated pointer is considered to be a live object by a garbage collector.

3. The method of claim 1 , wherein the reference count Is associated with information sufficient to locate the stored pointer In the reference table.

4. The method of claim 1 , further comprising:

determining whether a cache contains a second pointer to the object;

wherein If it is determined that the cache contains the second pointer:

inferring, based on the second pointer being in the cache, that the reference table contains the stored pointer; and

obtaining the shared pointer based on the second pointer; wherein If it is determined that the cache does not contain the second pointer: obtaining the stored pointer based on the first pointer:

inserting the stored pointer in the reference table;

obtaining the shared pointer based on the first pointer; obtaining the second pointer based on the first pointer: and adding the second pointer to the cache.

5. The method of claim 4, wherein the determining whether the cache contains the second pointer further comprises:

obtaining a weak pointer associated in the cache with the first pointer:

obtaining a third pointer based on the weak pointer:

determining whether the third pointer points to the object; and

upon determining that the third pointer points to the object, compute the second pointer based on the weak pointer.

6. The method of claim 1 , wherein the cache comprises a thread-local cache associated with a thread within the computer system and a global cache associated with a plurality of threads within the computer system, wherein the plurality of threads includes the thread, the method further comprising:

determining that the thread-iocai cache does not contain a second pointer to the object:

determining that the global cache contains the second pointer to the object;

adding a value based on the second pointer to the thread-local cache.

7. The method of claim 6, further comprising:

identifying an entry in the global cache associated with the first pointer; requesting an exclusive access to the entry; and

obtaining a weak pointer associated with the entry: and

reiinquishing the exclusive access.

8. The method of claim 1 , wherein ensuring that the stored pointer to the object exists in the reference table comprises;

identifying a slot in the reference table as an unused slot;

claiming the slot;

constructing the stored pointer based on the first pointer: and

storing the stored pointer in the slot.

9. The method of claim 1 , wherein the reference table is a multi-level table.

10. A system comprising :

a pointer receiver to receive a first pointer to an object;

a cache handler to determine that a cache does not contain a second pointer to the object;

a pointer creator to create a stored pointer and a shared pointer

corresponding to first pointer, the shared pointer having an associated reference count;

a reference count modifier to modify' the reference count to indicate a number of instances of the shared pointer within the computer system, where the number of instances include the shared pointer and each copy of the shared pointer; and

a pointer remover to remove the stored pointer from a reference table when the reference count indicates that there are no remaining instances of the shared pointer in the computer system.

11. The system of claim 10, wherein the reference count is associated with information sufficient to locate the stored pointer in the reference table.

12. The system of claim 10, wherein the cache comprises a thread-local cache associated with a thread within the computer system and a global cache associated with a plurality of threads within the computer system, wherein the plurality of threads includes the thread and the cache handler is further to:

determine that the thread-local cache does not contain a second pointer to the object;

determine that the global cache contains the second pointer to the object; and add to the thread-local cache a value based on the first pointer.

13. The system of claim 10, further comprising a pointer enumerator to enumerate each pointer in the reference table, wherein each object pointed to by an

enumerated pointer Is considered to be a live object by a garbage collector.

14. A non-transitory machine-readable storage medium comprising instructions executable by a processor of a computing device, the machine-readable storage medium comprising instructions to;

receive a first pointer corresponding to an object;

determine that no pointer corresponding to the first pointer exists in a local cache, the local cache corresponding to a first thread using trie first pointer;

determine that a second pointer corresponding to trie first pointer exists in a global cache, trie global cache corresponding to a plurality of threads including the first thread sharing a centrally managed data store;

create a stored pointer and a shared pointer corresponding to the first pointer, the shared pointer having a reference count;

add the stored pointer to a reference table;

modify the reference count to indicate a number of instances of the shared pointer within trie computer system, where the number of instances include the shared pointer and each copy of the shared pointer; and

remove the stored pointer from the reference table when trie reference count indicates that there are no remaining Instances of the shared pointer in the computer system.

15. The non-transltory machine-readable storage medium of claim 14 further comprising instructions to:

identify an entry in the global cache associated with the first pointer;

request an exclusive access to the entry;

obtain a weak pointer associated with the entry and;

relinquish the exclusive access.