Integrate reference and sub-object tags

Abstract

Managing secondary objects effectively increases garbage collection concurrency and reduces object storage requirements. The activity marking of secondary objects is integrated with the activity marking of referencing objects. Allocating a secondary object identifier field for the reference size in objects that are not primary objects is avoided; a dedicated bit is used together with the object relationship table to specify the primary object. A primary object is an object with at least one secondary object, and if the primary object is active, the garbage collector considers the at least one secondary object to be active, rather than a reference object of the primary object. Any reference objects of the active primary object will also be considered active. The code path for marking reference objects can be shared to allow more efficient secondary object marking. The primary-secondary object relationship can be represented in the slave handle and can be specified in a hash table or other data structure.

Description

Background Art

[0001] In computer programming, garbage collection (GC) helps provide automatic memory management. The "garbage" in question is memory space that has been allocated for use by a program and is no longer needed by that program, but cannot yet be used by other programs. The garbage collector attempts to identify such memory areas so they can be reclaimed for subsequent reallocation.

[0002] Garbage collection makes programming easier by freeing programmers from the need to manually free data objects that are no longer needed. Garbage collection also helps prevent some runtime errors, thereby enhancing network security by improving data integrity and availability. Many programming languages or runtime environments either require garbage collection or allow it as an option. Some software development environments allow both garbage collection and manual memory management within a given program.

[0003] Efficient implementation of garbage collection can be a high priority because the garbage collector may run frequently or at unpredictable times, or both, and may significantly slow down user program execution. In fact, most, if not all, garbage collectors sometimes utilize a "stop the world" approach that prevents user programs from running concurrently with the garbage collector. One could conceivably configure the garbage collector to run less frequently, or to give the garbage collector less time to do its job. However, simply reducing the amount of time spent on garbage collection without increasing garbage collection efficiency might significantly reduce the amount of memory reclaimed, for example, by increasing the time spent exchanging data between volatile and non-volatile memory devices or by exhausting available memory more quickly, which could hinder user program performance. Summary of the Invention

[0004] Some embodiments described herein provide improved efficiency during garbage collection, particularly with respect to secondary objects that are considered live (and therefore, not garbage) even though they are not referenced by their primary object when their corresponding primary object is live. Some embodiments integrate liveness marking of referenced objects with liveness marking of secondary objects. In particular, some embodiments reduce code space and complexity and reduce execution time by overlapping code paths for each marking. Some embodiments improve overall memory usage efficiency by avoiding allocating reference-sized secondary object identifier fields in objects that are not actually primary objects and therefore have no secondary objects. Other efficiencies may also be provided.

[0005] Some embodiments configured to use secondary objects for memory management assume or provide private spaces embedded in multiple objects. Each private space indicates whether the embedded object of the space is a primary object. Each private space is smaller than an object reference; in some embodiments, the private space is a single bit in the object. A primary object is an object that has at least one secondary object, and if the primary object is active, garbage collection considers the at least one secondary object to be active, rather than a reference object of the primary object. Any reference object of the primary object will also be considered active. During garbage collection marking, some embodiments treat secondary objects as reference objects by at least marking (i) all reference objects of each active object X and (ii) all secondary objects of each active object X as active. The reference object Y of object X is the object in the declared embedded field of X pointing to X.

[0006] For those skilled in the art, other technical activities and features related to the teachings of this document will also become apparent. The examples given are for illustrative purposes only. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Instead, this summary is provided to introduce some technical concepts in a simplified form, which will be further described in the detailed description below. The innovation is defined by the claims, as properly understood, and to the extent that this summary conflicts with the claims, the claims shall prevail. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed description will be provided with reference to the accompanying drawings, which depict only selected aspects and, therefore, are not intended to be exhaustive in their coverage or scope.

[0008] Figure 1 is a block diagram generally illustrating a computer system and generally illustrating configured storage media;

[0009] Figure 2 is a block diagram illustrating some aspects of some computer systems with enhanced memory management functionality;

[0010] Figure 3 is a schematic diagram illustrating aspects of the memory state at different points in time during a garbage collection process;

[0011] Figure 4 is a schematic diagram illustrating concurrent execution of a garbage collection thread and a mutator thread;

[0012] Figure 5 is a schematic diagram showing primary objects, secondary objects, and object references;

[0013] Figure 6 is a schematic diagram showing a hash table representing a primary and secondary relationship between objects;

[0014] Figure 7 is a diagram showing the bits in an object instance data structure;

[0015] Figure 8 is a flowchart illustrating steps in some memory management methods; and

[0016] Figure 9 is a flow chart further illustrating steps in some memory management methods. DETAILED DESCRIPTION

[0017] Overview

[0018] Innovations can extend beyond their origins, but understanding their origins can help people more fully understand them. In this case, some of the teachings described in this article were inspired by technical challenges faced by Microsoft innovators working to improve the performance of concurrent and non-concurrent garbage collection involving secondary objects. The innovators investigated the performance of concurrent garbage collection mechanisms with secondary objects. This performance investigation was a precautionary measure, intended to enable the direct creation of secondary objects through public APIs at some point in the future.

[0019] In some garbage collection environments, objects can contain extended references, for example, by using the slave GC handle type. A slave handle has a primary and a secondary object, where the secondary object is active only when the primary object is active (unless the secondary object is kept alive by another object). In some implementations, this increases the complexity of marking, because the primary object's information (info) is unaware of the secondary object.

[0020] Such secondary objects are already relatively rare because they are used only internally or in other ways that are largely or completely hidden from public API access. If the use of secondary objects increases as a result of making slave handle creation part of the public API, then the teachings provided herein will allow garbage collection of secondary objects to be efficiently scaled in a way that is not provided by well-known garbage collection methods.

[0021] Specifically, one technical challenge is how to make the collection of secondary object handles efficient and scalable. Another technical challenge is how to represent the master-subordinate relationship in an efficient and scalable manner. One approach is to continue listing the secondary object handles in a handle table that contains the primary object handle, the secondary object handles, and the non-primary object handles. Non-primary objects are objects that have space to contain a secondary object handle (and are therefore the primary object of that secondary object), but are not actually primary objects (i.e., they do not actually have any secondary objects).

[0022] But this handle table approach is inefficient because it involves looping through many non-primary objects to collect secondary object handles during garbage collection. It also does not scale well as non-primary objects are added because the addition of non-primary objects increases the work done to collect secondary object handles. Storing space for secondary object handles in each object is also inefficient because in many cases, this space is never used.

[0023] Some embodiments taught herein establish a mapping between a primary object and all of its secondary objects, such as in a hash table, a balanced tree, or other data structure. Entries for non-primary objects do not need to appear in the mapping data structure, which helps make it more efficient than a traditional handle table in identifying secondary objects.

[0024] Some embodiments automatically include in garbage collection both the references contained by the marking object and any secondary objects the object may have.Some embodiments further improve efficiency by sharing important code paths for both markings.

[0025] In addition, some embodiments embed an IS-PRIMARY bit in an object, which is set to indicate that the object is a primary object and, therefore, indicates that the object has one or more secondary objects, such as those identified in the above mapping. The IS-PRIMARY bit is cleared to indicate a non-primary object, i.e., an object with no secondary objects. Thus, these embodiments avoid allocating additional time slots in each object, as some less space-efficient methods do.

[0026] These are merely examples. Other aspects of these and other memory management embodiments are also described herein.

[0027] Operating Environment

[0028] refer to Figure 1 The operating environment 100 of an embodiment includes at least one computer system 102. Computer system 102 may or may not be a multi-processor computer system. The operating environment may include one or more machines in a given computer system, which may be clustered, client-server networked, and / or peer-to-peer networked within a cloud. A single machine is a computer system, and a group of cooperating machines is also a computer system. A given computer system 102 may be configured for end users, administrators, or as a server, distributed processing node, and / or in other ways, for example, through an application.

[0029] Human users 104 can interact with computer system 102 using a display, keyboard, and other peripherals 106 via typed text, touch, voice, movement, computer vision, gestures, and / or other forms of I / O. Screen 126 can be a removable peripheral 106 or an integral part of system 102. A user interface can support interaction between an embodiment and one or more human users. The user interface can include a command line interface, a graphical user interface (GUI), a natural user interface (NUI), a voice command interface, and / or other user interface (UI) presentations, which can be presented as different options or can be integrated.

[0030] System administrators, network administrators, cloud administrators, security analysts and other security personnel, operations personnel, developers, testers, engineers, auditors, and end users are each specific types of users 104. Automated agents, scripts, playback software, devices, and the like that act on behalf of one or more people can also be users 104, for example, to facilitate testing of the system 102. Storage devices and / or networking devices may be considered peripheral devices in some embodiments and may be considered part of the system 102 in other embodiments, depending on their separability from the processor 110. For example, Figure 1 Other computer systems not shown may technically interact with computer system 102 or another system embodiment using, for example, one or more connections to network 108 via a network interface device.

[0031] Each computer system 102 includes at least one processor 110. Like other suitable systems, computer system 102 also includes one or more computer-readable storage media 112. Storage media 112 can be of different physical types. Storage media 112 can be volatile memory, non-volatile memory, fixed in place media, removable media, magnetic media, optical media, solid-state media, and / or other types of physically durable storage media (rather than just propagated signals or just energy). Specifically, a configured storage medium 114, such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile storage medium, can functionally become a technical part of the computer system when inserted or otherwise installed, making its contents accessible to processor 110 for interaction with and use by processor 110. Removable configured storage media 114 is an example of computer-readable storage media 112. Some other examples of computer-readable storage media 112 include built-in RAM, ROM, hard disks, and other memory storage devices that are not readily removable by the user 104. For purposes of current U.S. patent requirements, neither computer-readable media, computer-readable storage media, nor computer-readable memory itself is a signal per se or pure energy under any pending or issued U.S. claim.

[0032] Storage medium 114 is configured with binary instructions 116 that can be executed by processor 110; "executable" is used broadly herein to include, for example, machine code, interpretable code, bytecode, and / or code running on a virtual machine. Storage medium 114 is also configured with data 118, which is created, modified, referenced, and / or otherwise used for technical effect through the execution of instructions 116. Instructions 116 and data 118 configure the memory or other storage medium 114 in which they reside; when such memory or other computer-readable storage medium is a functional part of a given computer system, instructions 116 and data 118 also configure that computer system. In some embodiments, portions of data 118 represent real-world items such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, and the like. This data is also transformed through backup, restore, submission, abort, reformatting, and / or other technical operations.

[0033] Although the embodiments can be described as software instructions executed by one or more processors in a computing device (e.g., a general-purpose computer, a server, or a cluster), such description is not intended to be exhaustive of all possible embodiments. It will be understood by those skilled in the art that identical or similar functions can also be generally implemented in hardware logic in whole or in part, to provide identical or similar technical effects. Alternatively, or in addition to software implementations, the technical functions described herein can be performed at least in part by one or more hardware logic components. For example, and without excluding other implementations, an embodiment may include hardware logic components 110, 128, such as field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip components (SOCs), complex programmable logic devices (CPLDs), and similar components. For example, the components of an embodiment can be grouped into interactive functional modules based on their inputs, outputs, and / or their technical effects.

[0034] In addition to the processor 110 (e.g., CPU, ALU, FPU, TPU and / or GPU), memory / storage medium 112 and display 126, the operating environment may also include other hardware 128, such as batteries, buses, power supplies, wired and wireless network interface cards. The terms "screen" and "display" are used interchangeably herein. The display 126 may include one or more touch screens, a screen that responds to input from a pen or tablet, or a screen that operates only for output. In some embodiments, peripheral devices 106, such as human user I / O devices (screen, keyboard, mouse, graphics tablet, microphone, speaker, motion sensor, etc.), are in operable communication with the one or more processors 110 and memory.

[0035] In some embodiments, the system includes multiple computers connected via a wired and / or wireless network 108. The network interface device 128 can provide access to the network 108 using network components such as packet-switched network interface cards, wireless transceivers, or telephone network interfaces, which may be present in a given computer system. Virtualization of the network interface device and other network components, such as switches or routers or firewalls, can also occur, for example, in a software-defined network or sandbox or other secure cloud computing environment. In some embodiments, one or more computers are partially or completely "air-gapped" by being disconnected or only intermittently connected to another networked device or a remote cloud. Specifically, the memory management functionality taught herein can be installed on an air-gapped system and then updated periodically or occasionally using removable media. A given embodiment can also transfer technical data and / or technical instructions via direct memory access, removable non-volatile storage media, or other information storage-retrieval and / or transmission methods.

[0036] Those skilled in the art will appreciate that the foregoing and other aspects described herein under the "operating environment" may form part of a given embodiment. The headings herein are not intended to strictly categorize features into embodiment and non-embodiment feature sets.

[0037] One or more items are shown in dashed outline form in the figures, or listed in parentheses, to emphasize that they are not necessarily part of the operating environment or all embodiments shown, but can interoperate with the operating environment or items in some embodiments discussed herein. This does not mean that any figure or any embodiment does not require items that are not in dashed outline or in parentheses. In particular, Figure 1 is provided for convenience; Figure 1 The inclusion of an item does not imply that the item or the described use of the item was known prior to the current innovation.

[0038] More about the system

[0039] Figure 2Aspects of some systems 200 are shown that are systems 102 enhanced with at least some of the functionality 202 taught herein for memory management involving secondary objects. Specifically, the enhanced system 200 shown includes a garbage collector (GC) 204 that is installed in a GC thread 206 or in a GC marking phase code 210 or in another location. The enhanced GC has one of the following features: the GC integrates reference marking with secondary object marking, the GC avoids relying on a reference size field embedded in an object to indicate whether an object is a primary object, or the GC avoids cycling through non-primary object handles to collect secondary object handles. These features of functionality 202 help storage efficiency 944 by reducing storage of objects, and help computational efficiency 944 by reducing the computational requirements and computational complexity of GC marking in both concurrent and non-concurrent garbage collection.

[0040] In many cases, mutator thread 208 may be a user thread, ie, a thread running in a user address space. However, the same tools and techniques taught herein may be applied to garbage collection performed on threads running in kernel address space.

[0041] The memory 112 of the illustrated system 200 includes a plurality of objects 212, such as objects allocated in a heap 214. As shown, an object 212 can be a primary object 216 with one or more secondary objects 218, or an object can be a non-primary object 220. A secondary object Y of a primary object X can itself be a primary object, as Y can have its own secondary object Z. Each of the primary, secondary, and non-primary objects can be active 222 or inactive 222. Regardless of the primary-secondary relationship or the lack thereof, each of the primary, secondary, and non-primary objects can have zero or more references 224 to other objects. Handles 224 of the non-primary objects can be stored (at least) in a handle table 228. For example, the handle table 228 can be implemented using data structures such as arrays, trees, indices, hashes, or pointers.

[0042] like Figure 2 As shown, objects 212 and other portions of memory 112 may be reachable 230 or unreachable 232 during the garbage collection mark phase, may be marked 234 or unmarked 236 by the GC mark phase, and may be in use 238 by software other than the GC, with such software using 240. Memory that is unused but not yet identified as reclaimable may be considered floating garbage 226.

[0043] As mentioned above, the enhancement 202 may include the integration of reference object tags with secondary object tags. This integration may be achieved through a shared code path for both tags. Figure 2Also shown are code paths 246, along with a metric 244 for measuring the extent of any overlap 242 (sharing) of the code paths. However, integration can also be apparent due to the lack of detail required to call marking. In some embodiments, a caller of the top-level GC marking routine simply asks the marking routine to obtain references and mark them, without the details of an explicit request for subordinate handle marking. With this integrated code, the caller does not need to know about the associated handle marking or other auxiliary marking, and auxiliary marking does not require special handles except at the level of individual objects.

[0044] Figure 3 and Figure 4 Some aspects of garbage collection are further explained. Some of these aspects are well known or occur in well known garbage collection activities, but their relevance to the teachings herein becomes clear only after understanding the innovative garbage collection marking.

[0045] like Figure 3 As shown, the garbage collection code operates on a segment 300 of memory 112 that is divided by program execution into contiguous regions 302. A given region 302 is apparently being used by one or more mutator threads, such as Figure 3 A given area 302 may also be clearly not in use and therefore recyclable, as shown by the check mark symbol in FIG. Figure 3 The recyclability of region 302 may also be uncertain.

[0046] Garbage collection typically involves tracking addresses or otherwise determining the used or unused status of memory areas and marking 308 the memory areas (or data structures representing the areas) accordingly. Some garbage collectors leave the marked areas where they are found, and then the programs 120, 122, 124 are allocated memory outside of the reclaimable areas. This approach is adopted in so-called mark-and-sweep garbage collection algorithms. Other garbage collectors relocate used areas or relocate reclaimable areas, or both, in order to compact 306 multiple areas with the same reclaimability status together. This approach, known as mark-and-compact, typically produces larger reclaimable areas 304 than the mark-and-sweep approach, but has greater complexity due to the need to correctly update addresses to match the compaction results.

[0047] Figure 3 and Figure 4It is helpful to illustrate the stages or sub-stages 402 of garbage collection and their relationship to concurrency when there is some concurrency. These figures show some specific stages in the garbage collection cycle, including: the marking stage 308, the sweeping stage 404 and the compaction stage 306. During the marking 308 period, reachable objects 230 or other non-recyclable memory areas are marked in the correct location or in the data structure representing them. During the sweeping 404 period, recyclable objects are removed from the heap 214, for example by being placed in a pool for reallocation. During the compaction 306 period, recyclable areas are put together, which can also be regarded as putting used areas together. A given garbage collector does not necessarily perform every stage, for example, sometimes the compaction 306 can be omitted.

[0048] A simple approach to garbage collection is to simply pause everything except the garbage collector while the garbage collector marks 308 a memory area as being in use or reclaimable. However, this complete "stop the world" approach is unacceptable in most systems because it degrades user program performance too severely. Therefore, the garbage collector can be designed with the following goal: to limit the long "stop the world" subphase 406 by allowing concurrent execution of the garbage collection thread 206 and any (multiple) mutator threads 208. The marking phase can be subdivided into a concurrent part and a non-concurrent part. The use of function 202 tends to increase concurrency during marking, and therefore tends to improve the performance of user code that is subject to garbage collection. Although concurrency involves at least two threads overlapping in execution for at least part of the time, concurrency does not require that the two threads always start together or pause together or stop together.

[0049] Figure 5 Further shown are objects 212. In this example, object A is a primary object 216 with a secondary object C. Object A also references a reference object 502 using an embedded reference 224 labeled f0. Thus, Figure 5 Two references 224 are shown, namely, one in pointer variable 504 that references Object A and one in Object A that references Object B.

[0050] In this example, format information 506 is also embedded in object A. For example, the format information structure 506 may indicate the type and offset of the fields or other members of object A. Those skilled in the art will recognize that although Figure 5The arrow with one edge pointing to a given object indicates that the address used to identify the object is the address of the first byte of the object, but in practice, an implementation of object-oriented programming may use an address that identifies a non-zero offset in the area 302 allocated to the object. For example, the address may point to the byte following the predefined header portion 506 containing format information or other metadata. Those skilled in the art may modify the teachings herein accordingly.

[0051] Figure 6 A hash table 602 is shown representing master-subordinate relationships. In this example, each master-subordinate relationship is part of a slave handle 606. In this example, each slave handle 606 has its own entry 604 in the hash table 602, and the entries are organized according to the hash code of the master object. In the shown portion of the table 602, the first entry shows that object C is a slave of object A, and the second entry shows that object D is a slave of object C. Some embodiments hash the addresses of master objects and link the handles together so that queries about a master object can quickly provide all the slaves of the queried master object. In a compacting garbage collector, some master object addresses may change, after which they are rehashed. More generally, in some embodiments, handles are used to track master-subordinate object relationships, rather than using a dedicated reference-sized space in each object that could potentially become a master object.

[0052] Figure 7 Memory configured as the format information portion 506 of an object is shown, including bits 700 that can be used to indicate information such as the data type and size or offset of each member of the object. According to the teachings herein, the well-known instance format information can be enhanced to include an IS-PRIMARY bit 702 that indicates whether the object is a primary object. If the object is a primary object, one or more secondary objects of the object are identified, for example, in a hash table 602. Figure 7 The location of the IS-PRIMARY bit 702 in is illustrative only and is not mandatory.

[0053] Some embodiments provide 942 the advantage that secondary objects can be used without requiring each object to have a large enough space to accommodate the reference (unlike some other approaches). This embodiment reserves one bit (the IS-PRIMARY bit) for each object, plus space for the actual primary and secondary object identifiers. This saves space as the number of objects 212 increases. The runtime environment 100 can have several spare bits 700 that can be used for similar situations, so once the teachings herein are understood, implementing such a bit 702 need not be very disruptive to the code base of an existing runtime.

[0054] Another advantage of some embodiments is that marking secondary objects is combined with marking reference objects. This allows for relatively less disruption to existing GC code by having existing code 210 also do different work, thereby utilizing existing code 210 for marking.

[0055] In particular, some embodiments utilize or provide a system, such as system 200 or another system 102, configured to utilize secondary objects 218 for memory management 936 as described herein, for enhanced secondary object memory management functionality. The enhanced system 200 includes a memory 112 and a processor 110 in operable communication with the memory. The processor 110 is configured to perform memory management steps, including (a) indicating, in a dedicated space 704 embedded in a plurality of objects 212, whether a corresponding object in the plurality of objects is a primary object 216, each dedicated space being smaller than an object reference 224, the primary object being an object having at least one secondary object 218 that is considered active by garbage collection, rather than a referenced object of the primary object, if the primary object is active, and (b) during garbage collection marking, treating the secondary objects 218 as referenced objects 502 by at least marking (i) all referenced objects for each active object X and (ii) all secondary objects for each active object X as active. The enhanced system 200 integrates the marking of reference objects with the marking of secondary objects during garbage collection to reclaim memory for further use without requiring objects 220 that are not primary objects to be embedded in a reference-sized space to hold references to secondary objects.

[0056] Some embodiments also include a hash table 602 having entries 604. Each hash table entry includes a primary object reference 224 pointing to a primary object 216 and a secondary object reference 224 pointing to a secondary object 218, thereby indicating that the secondary object is a secondary of the primary object. In other embodiments, other data structures are used to represent the primary-secondary relationship. Regardless of the specific data structure used, such a representation can advantageously be limited to objects that are actually involved in the primary-secondary relationship, unlike the inefficient method of actively allocating space in each object just in case the object operates as a primary object.

[0057] In some embodiments, each dedicated space 704 embedded in an object to indicate whether an object is a primary object consists of a single bit. Those skilled in the art will appreciate that in different implementations, this bit may be labeled differently, for example, in internal prototypes, bit 702 may be called a "HAR" bit ("reference added"), while in Figure 7 The middle bit 702 is labeled the "IS-PRIMARY" bit.

[0058] Regardless of the marking, embodiments can avoid the inefficiency of a dedicated secondary object reference space in each object. This avoidance saves space even when non-primary objects do have references 224 to referenced objects 502. Specifically, in some embodiments, objects 212 includes object Z 220, which is not a primary object, but object Z has no secondary objects and does not embed any references.

[0059] In some embodiments, a primary object has multiple secondary objects. Thus, some objects 212 include a primary object Y 216 having at least two secondary objects 218.

[0060] In some embodiments, a secondary object may itself be a primary object. Thus, some objects 212 include a secondary object Q 218 that is also a primary object 216.

[0061] A production scenario helps illustrate the space-saving benefits of some embodiments. In some embodiments, at most ten percent of the objects 212 of a program executed at least in part in the enhanced system 200 are primary objects 216. Thus, by using as little as one bit 702 to indicate that they are not primary objects, rather than using a field of a NULL reference size such as a pointer field, at least 90% efficiency 944 is contributed. This savings may be partially offset by the storage required for a hash table or other primary-secondary relationship representation data structure 602, but overall, using a bit in each object instead of using a pointer in each object saves space. Those skilled in the art will understand that this maximum 10% is merely an example ratio that is met in some cases, and is not an absolute requirement for every embodiment.

[0062] In some scenarios, a program executed at least in part in the enhanced system 200 has at least ten thousand objects 212, each of which has a respective embedded private space 704 of no more than four bits to indicate whether the object X is a primary object. Each object X also lacks any embedded private space greater than four bits to identify any other object as a secondary object of object X.

[0063] Other system embodiments are also described herein, either directly described or derivable as system versions of the described processes or configured media, informed by the extensive discussion of computing hardware herein.

[0064] Although specific structural examples are shown in the drawings, embodiments may deviate from these examples. For example, items shown in different drawings may be included together in an embodiment, items shown in a drawing may be omitted, functions shown in different items may be combined into fewer items or a single item, items may be renamed, or items may be connected differently to each other.

[0065] The examples provided in this disclosure are provided to help illustrate various aspects of the technology, but the examples given herein do not describe all possible embodiments. A given embodiment may include, for example, additional or different technical features, mechanisms, sequences, data structures or functions, and may deviate from the examples provided herein in other ways.

[0066] Process (also known as method)

[0067] Figure 8 Shown is a family of methods 800 that may be performed or facilitated by an enhanced system, such as system 200 , or another enhanced system as taught herein. Figure 9 Further shown is a memory management method (which may also be referred to as a "process" in the legal sense of the word) suitable for use during operation of a system having the innovative functionality taught herein. Figure 9 Including Figure 8 Some improvements, additions, or contextual actions to the steps shown. Figure 9 Also includes Figure 8 The steps shown. Unless otherwise indicated, the technical processes shown in the figures or otherwise disclosed will be performed automatically, such as by garbage collection code that reads space 704 and object constructor code that initializes space 704. To the extent that actions by a human administrator or other person are involved, the processes may also be performed partially automatically and partially manually, for example, in some embodiments, a developer may specify the relative frequency of garbage collection cycles. No innovative process is contemplated herein to be entirely manual. In a given embodiment, zero or more of the steps shown in the process may be repeated, or different parameters or data may be used for the operation. The steps in the embodiments may also be performed in a manner similar to Figure 8 and Figure 9 The steps may be performed in a different order from the top-to-bottom order shown. The steps may be executed serially, in a partially overlapping manner, or completely in parallel. Specifically, the order in which the control flow diagram 800 action items or the control flow diagram 900 action items are traversed to indicate the steps performed during the process may vary from one execution of the process to another execution of the process. The chart traversal order may also vary from one process embodiment to another process embodiment. As long as the performed process is operational and complies with at least one claim, the steps may also be omitted, combined, renamed, regrouped, performed on one or more machines, or otherwise deviate from the illustrated flow.

[0068] Some embodiments use or provide a method for computing system memory management 936 using secondary objects, including automatically performing the following steps: indicating 802 whether a corresponding object in a plurality of objects is a primary object in a private space 704 in which the plurality of objects are embedded, each private space being smaller than an object reference, a primary object being an object having at least one secondary object that, if the primary object is active, is considered active by garbage collection, rather than a reference object of the primary object; treating 902 the secondary objects as reference objects during garbage collection marking 308 by at least marking 806 as active objects 222 (i) all reference objects 502 for each active object X and (ii) all secondary objects 218 for each active object X; and avoiding 812 embedding 816 in an object 220 that is not a primary object a space of any reference size for holding references 224 to the secondary objects 218. Additional garbage collection processing, such as compaction 306 or sweeping 404, may also be performed 814.

[0069] In some embodiments, at least a portion of the garbage collection marking follows 904 the code path 246 shared by the secondary object marking and the reference object marking, at least to the point where each object is checked for liveness. For example, in some embodiments, the same code path is traced to a call to the go_through_objects macro or another call to the lowest routine (the finest granularity) that marks each object. In these embodiments, code above this granularity does not distinguish between reference objects and secondary objects with respect to GC marking.

[0070] As another example, the following pseudocode illustrates the use of go_through_objects:

[0071]

[0072] As another example, in some embodiments, at least a portion of garbage collection marking follows 904 a code path 246 shared by secondary object marking and reference object marking, at least to the point where object references are enumerated to support checking 906 the liveness of various objects. For example, in some embodiments, the same code path is traced to a GetNextReference() call or another call to the lowest routine (finest granularity) that obtains the address of the object to be marked.

[0073] Some embodiments provide 942 better performance by marking objects faster than earlier methods. For example, some embodiments avoid 916 relying on looping through a handle table that includes non-primary objects to collect secondary object handles. Some embodiments avoid 920 relying on activity incrementing counters 922 to collect secondary object handles.

[0074] Before returning 926 a handle to an object as a result of a request to create the object, some embodiments set 924 a bit 702 embedded in the object to indicate that the object is a master object.

[0075] Some embodiments use 928 a hash table to designate that an object is a secondary of a primary object. In some embodiments, a hash table or other data structure associates multiple secondary objects with a single primary object. Thus, some embodiments use 928 a data structure 602 to designate that Object X and Object Y are each a secondary of Primary Object Z. Some embodiments include an API to update the hash table or other data structure based on, for example, a SetPrimary() or SetSecondary() call. Some methods 900 include receiving 910 a command to replace 912 at least one object of a particular primary-secondary relationship and, while executing the command, updating 914 a data structure that specifies the primary-secondary relationship.

[0076] In some cases, some embodiments treat secondary objects as primary objects and mark them accordingly.In some methods, treating 930 secondary object X as its own primary object includes marking 308 each reference object of object X and marking each secondary object of object X.

[0077] Configured storage media

[0078] Some embodiments include a configured computer-readable storage medium 112. The storage medium 112 may include a disk (magnetic, optical, or other), RAM, EEPROMS or other ROM, and / or other configurable memory, particularly including computer-readable storage media (which is not merely a propagated signal). The configured storage medium may particularly be a removable storage medium 114, such as a CD, DVD, or flash memory. The general purpose memory may be removable or non-removable, volatile or non-volatile, and may be configured in an embodiment that utilizes, for example, an IS-PRIMARY bit 702 or other space 704 dedicated to indicating primary, primary objects 216, secondary objects 218, slave handles 606, a master-slave relationship data structure 602, and an overlay code path 246 that integrates reference object tags with secondary object tags during garbage collection 938, in the form of data 118 and instructions 116, wherein the data 118 and / or instructions 116 are read from the removable storage medium 114 and / or other sources such as a network connection. As disclosed herein, the configured storage medium 112 enables the computer system 102 to perform the technical process steps for memory management of secondary objects. Thus, the figures help illustrate configured storage medium embodiments and process (also known as method) embodiments, as well as system and process embodiments. Specifically, Figure 8 or Figure 9Any process steps shown in or taught herein may be used to help configure a storage medium to form a configured storage medium embodiment.

[0079] Some embodiments use or provide computer-readable storage media 112, 114 configured with data 118 and instructions 116 that, when executed by at least one processor 110, cause a computing system to perform a memory management method using secondary objects. The method includes: indicating 802 whether a corresponding object in a plurality of objects is a primary object 216 in a dedicated primary space 704 embedded in the plurality of objects, each dedicated space 704 being smaller than an object reference 224, the primary object being an object having at least one secondary object 218 that would be considered active by garbage collection if the primary object were active, rather than a reference object of the primary object; treating 902 the secondary objects as reference objects during garbage collection marking 308 by at least marking (i) all reference objects 502 of each active object X and (ii) all secondary objects 218 of each active object X as active; and avoiding 812 embedding 816 in objects that are not primary objects any reference-sized spaces for holding references to secondary objects, each reference-sized space being at least 32 bits in size.

[0080] In some embodiments, the integration of secondary object tags and reference object tags contributes to the code balance and performance speed benefits of embodiments. In some embodiments, this integration includes overlapping 242 code paths. The code paths overlap to the extent that they follow the same execution path.

[0081] Overlap 242 can be measured in a variety of ways. For example, overlap can be measured at the stack level. Assume that individual letters represent corresponding methods or other routines called along an execution path. Then path ABCDEFGKLM and path ZYABCDEFGR have overlap ABCDEFG. If ABCDEFGKLM is the reference object marking path and ZYABCDEFGR is the secondary object marking path, then the overlap of ABCDEFG is 70% of the reference object marking path. Alternatively, overlap 242 can be measured based on shared code blocks, shared code lines, or shared instructions. Unless otherwise specified, any of these metrics 244 can be used, and the overlap percentage is the largest percentage. More generally, when enhanced GC marking 308 is performed, there is a common code path that performs the "get references and mark them" work. Because subordinate handle marking is integrated into this common code, callers above the individual object marking level do not need to know the difference between reference object marking and secondary object marking, and no special handling is required when implementing functionality 202 into a previously unenhanced system 102.

[0082] Specifically, in some embodiments, the method includes following 904 a reference object marking code path 246-RO to mark reference objects during garbage collection, and includes following 904 a secondary object marking code path 246-SO to mark secondary objects during garbage collection. In some of these embodiments, at least 50% of the reference object marking code path overlaps 242 with the secondary object marking code path. The overlap 242 is measured under at least one of the following overlap metrics 244, whether including library code, excluding library code, or both, and whether following all executed paths, all possible paths, or only the shortest path: number of lines of code, number of compiler-generated instructions, number of routines called, or number of stack frames.

[0083] In some embodiments, integrated reference marking and secondary object marking provide greater flexibility because slave handle marking can be performed earlier, rather than being the last sub-phase of marking 308. Without this flexibility, slave handle marking may need to be the last sub-phase in order to obtain complete results from all sub-phases that can make objects active, and thus be able to mark all secondary objects of the active master object. However, this inflexibility conflicts with making other sub-phases the last sub-phase of marking 308, potentially resulting in multiple instances of the purported "last" sub-phase being cleared one after another.

[0084] In some embodiments, an enhanced marking method for secondary objects integrated with reference object marking avoids 932 imposing 934 a stop-the-world state 406 by performing garbage collection marking of secondary objects concurrently with the execution of an application 810. In practice, in some embodiments, the method is implemented as part of a background garbage collector. Thus, the method is executed 940 as part of a concurrent garbage collection. In other embodiments, the method is executed as part of a non-concurrent garbage collection. In either case, the method can improve performance by reducing the length of one or more stop-the-world subphases.

[0085] In some embodiments, execution speed is improved relative to some existing methods because the embodiments avoid 916 looping 918 through any handle data structure including handles to primary objects 216 and non-primary objects 220 to collect handles to secondary objects 218 for tagging 308 dependencies.

[0086] Additional details, examples, and observations

[0087] The following provides additional support for the above discussion. For convenience, this additional support material appears under different headings. Nevertheless, it is intended to be understood as an integrated and integral part of the discussion of the intended embodiments of the present disclosure.

[0088] Concurrent slave handles and finalization scans

[0089] Background Garbage Collection (BGC) is a concurrent style of GC that is optimized for latency, in part by shortening the Stop-the-Walk portion. The flow of a non-enhanced BGC consists of an Initialization phase (completed in a Stop-the-Walk phase), followed by a Concurrent Marking phase (not a Stop-the-Walk phase), followed by a Final Mark phase (a Stop-the-Walk phase), followed by a Sweep phase. The Final Mark phase in this BGC consists of a Catch-Up subphase, a Dependent Handle Marking subphase, a short Nulling subphase, a Final Sweep subphase, and a long Nulling subphase.

[0090] In this BGC example, the main marking work is done concurrently with the user threads; sweeping is done concurrently. Both Init and Final Mark are STW-style and are typically very short. Init determines that a BGC cycle should be executed and traverses the call stack to fill in the stack roots (no marking is done at this time). Final Mark is a catch-up to obtain an accurate description of the memory management state. Catching up consists of obtaining the current roots and marking them again; since most objects have already been marked, this part of marking is usually completed quickly. Catching up also involves revisiting modified parts of the heap. Since most objects have already been marked, there is usually not much to do here (this example performs revisits concurrently during concurrent marking, so revisits during STW are also typically very fast).

[0091] At this point, the BGC knows which objects should be active, except for constructs concerning any of the following categories.

[0092] Finalizable objects: The Backfill Collection (BGC) should traverse finalizable objects and promote any dead objects it discovers, along with the objects they hold. This is called a finalization sweep. Finalization can be used to help manage the lifecycle of managed objects, for example by adding them back to the pool when the GC indicates they are dead (finalizers run). Promoting discovered dead finalizable objects (so their finalizers can run) and their children can take a significant amount of time.

[0093] Dependent Handles: The BGC should walk the primary targets of Dependent Handles (DHs), and for active primary objects, promote their secondary objects (treating them as active). If any secondary object causes the primary object of any DH to be active, the BGC should do the same for that DH. This is called a DH scan. DHs used to be rare because they were only used in the Core Language Runtime for edit and continue. Then some runtime uses of DHs were added, for example, using dependent handles to interact with XAML. Then the Core Language Runtime exposed ConditionalWeakTable. At this time, it was not uncommon for some code to use DHs, so the time required to promote objects due to DHs could also be long when using non-enhanced code.

[0094] NULLing: If the target of a short or long weak handle is found dead, it is NULLed. Note that in this example, DH uses long weak semantics, so they will be NULLed by the long weak handle (for example, in one implementation, both are done in GCScan::GcWeakPtrScan). If there are many handles, NULLing the short / long weak handle targets may take a while, but the NULLing itself is fast, so generally this is not a substantial performance issue.

[0095] These types of constructs are typically optional in applications 124. However, if they are present, this example BGC processes them during the final mark phase of STW completion. As the size of the heap grows, the chances of final mark taking longer increases if the code uses any or all of these types of constructs. The teachings herein can be applied to reduce latency by making garbage collection more concurrent (e.g., by reducing or eliminating STW subphases).

[0096] Some legacy code does not publicly publish dependent handle types to user code, and user code can only create dependent handles indirectly by using the BCL API. The BCL (Base Class Library) is the lowest layer of managed code, built on top of the runtime. Implementations of this BCL API can allocate or release dependent handles. To the runtime, the BCL is user code, but not end-user code, because the BCL can communicate with the runtime in ways that end-user code cannot, such as creating dependent handles. At some point, dependent handles may be publicly published to end-user code. In terms of this publication increasing the use of dependent handles, the functionality 202 taught herein can provide 942 performance benefits.

[0097] When considering how to enhance the traditional BGC with improved functionality 202, one goal is scalability. In some scenarios, there may be an arbitrary number of objects ready for finalization, or an arbitrary number of dependent handles. If these can be run simultaneously or nearly simultaneously with the application code, the performance improvement can be more desirable.

[0098] In some scenarios, another consideration is how to preserve current program semantics. Some environments include patterns where user code uses both short and long weak handles to point to the same object, and the code assumes that if the target of the short weak handle is null and the target of the long weak handle is not null, then the finalizer will be run. Some embodiments preserve this behavior while making things more concurrent. In some cases, the long-weak semantics of DH are preserved.

[0099] Another consideration in some scenarios is how to make DH scanning faster. In some legacy code, DH scanning is done as a separate step, as DH is considered an add-on. Non-enhanced DH scanning uses a simple algorithm with poor performance. Non-enhanced DH scanning also doesn't integrate well with the rest of BGC, as it attempts to be the last step in the marking process. This is difficult to handle, as the DH scan itself may introduce other work, such as marking overflows, resulting in alternating handling of marking overflows and scanning DH. If there is another type of root, this could also try to interleave it, further confusing the code flow and design.

[0100] The teachings of this article address two deficiencies of non-enhanced DH scanning. They describe an enhanced method for handling DH scanning and making it more concurrent. Keeping the following observations in mind, one can see how to incorporate enhanced DH scanning into existing marking codes.

[0101] First, a DH or other master-subordinate relationship states that if the primary object is considered active, then its subordinate objects should also be considered active. This lifecycle consideration applies to any references contained by the primary object; if the object is marked (considered active), then all its references should also be marked. And if the object is the primary of a DH or multiple DHs, then its corresponding subordinate object or objects should also be marked.

[0102] Second, when the GC marks an object, it retrieves the references it contains and marks them. In some legacy code, this is done in a routine called go_through_objects, which decodes information telling the GC where to find the references it contains. If the enhanced code discovers that the object has corresponding secondary objects, it can also integrate these secondary objects into the references for marking purposes, so that go_through_objects or similar object relationship tracking routines in other implementations will also mark them. Besides being marked, secondary objects do not become reference objects; for example, a debugger cannot trace from a primary object to a secondary object by simply following the address embedded in the primary object.

[0103] Some embodiments include an IRM function 202, where IRM is an abbreviation for integrated reference tagging. Because the IRM function 202 integrates reference object tagging and sub-object tagging, it can also be called "integrated reference and sub-object tagging." According to the IRM function 202, the tag 308 is aware of the integrated references added by the DH. When the IRM function 202 is added, the code path that calls go_through_objects, etc. can remain unchanged because the IRM will automatically include all references contained by each object (traditional references or references to sub-objects). This is a much better solution than the previous separate DH scan, and it is easier to make the DH scan concurrent by leveraging the concurrent tagging of pre-existing reference object scans.

[0104] One aspect of the IRM function 202 is the way in which the secondary objects are identified which correspond to the primary object. The enhancement code should identify when to check for secondary objects of an object. This is accomplished by using and checking the IS-PRIMARY bit. This bit is set to indicate that one or more secondary objects exist; a given primary object can have multiple secondary objects. In one implementation, the IS-PRIMARY bit is embedded in the syncblock on 64-bit systems. This does not preclude the implementation of a 32-bit address space, but the relative performance gain may be greater on 64-bit systems because they can have a much larger heap than a 32-bit system.

[0105] The enhanced code 202 with IRM functionality should also be able to obtain secondary objects of objects with the IS-PRIMARY bit set. Some embodiments include a hash table 602 that is a DH primary object. To avoid problems from unstable hashing, some embodiments use the hash code of the primary object as the hash table key. This table 602 should be built using DH operations, for example, when a primary object is set for DH, it should be inserted into the primary hash table with its secondary object as its value (or as one of the values if there are multiple secondary objects with that primary object). If the DH primary object is changed, the old primary object will be deleted from the hash table and the new primary object will be inserted. To avoid very fine synchronization when the BGC is also looking at the hash table, some embodiments can have the BGC acquire a lock (STW) and work for a short period of time before releasing the lock.

[0106] In this way, DH scanning can be folded into normal marking. However, in some scenarios, an additional consideration is how to record modifications in DH so that they will be tracked by revisiting code. In traditional code, heap modifications are sometimes tracked by write barriers, which record modifications in a write monitoring table. To achieve a similar effect to DH marking, some embodiments record modifications to the primary of DH so that the marking code will revisit those modified secondaries. For the handle table, the code may have called a handle table write barrier (e.g., HndWriteBarrier or similar barriers in other environments) to adjust the age. Enhancement code can take this opportunity to use the write barrier code to also record the primary object in the write monitoring table.

[0107] Additionally, some embodiments omit a separate DH scan in the final marking. If any modifications are made to the slaves of a master, they are reflected through the handle table write barrier, so the master is naturally re-accessed. If a new master is added (by modifying the master of the DH or allocating a new DH), its slaves are already created before garbage collection pauses the execution engine. In STW, the garbage collector has access to the relationships from the slaves to the master, so if the master is marked, the garbage collector can determine which slaves should also be marked.

[0108] One flow of the enhanced BGC includes an Int initialization phase (STW), followed by a concurrent marking phase with integration marking (non-STW), followed by a final marking phase with integration marking, which also performs catch-up and short weak zeroing (STW), followed by a parallel completion scan phase with integration marking (non-STW), followed by long weak zeroing (STW), followed by a scan phase. This enhanced BGC workflow will tend to have a shorter STW time than the non-enhanced BGC workflow described above, thereby improving application performance.

[0109] Technical Features

[0110] The technical features of the embodiments described herein will be apparent to one of ordinary skill in the art and will also be apparent in many respects to a broadly focused reader. Some embodiments address technical activities such as setting or clearing bits, tracking pointers, allocating memory, creating or updating hash tables, and managing memory in a computer system, each of which is an activity deeply rooted in computing technology. Some of the technical mechanisms discussed include, for example, embedded bits, typo information structures, objects, object references, hash tables, handles, and code examples. Some of the technical effects discussed include, for example, reducing storage requirements for non-primary objects, integrating reference object marking with secondary object marking during garbage collection, increasing concurrency, reducing STW time, and avoiding particular inefficiencies during garbage collection. Therefore, pure spirit is obviously excluded. Based on the description provided, other advantages of the technical features based on the teachings will also be apparent to those skilled in the art.

[0111] Some of the embodiments described herein may be viewed by some in a broader context. For example, concepts such as whether something is in use, size, collection, management, and relationships may be considered relevant to a particular embodiment. However, this does not mean that exclusive rights to abstract concepts are sought herein; they are not. Instead, the present disclosure focuses on providing appropriate specific embodiments whose technical effects fully or partially solve a specific technical problem, such as how to increase garbage collection concurrency for application software. Other configured storage media, systems, and processes involving usage status, size, collection, management, or relationships are not within the scope. Therefore, with a proper understanding of the present disclosure, ambiguity, pure abstraction, lack of technical characterization, and the attendant proof problems are also avoided.

[0112] Additional combinations and variations

[0113] Any combination of code, data structures, logic, components, communications, and / or their functional equivalents may also be combined with any of the above systems and variations thereof. A process may include any subset or combination or operable sequence of any of the steps described herein. Each variation may occur alone or in combination with any one or more other variations. Each variation may occur with any process, and each process may be combined with any one or more other processes. Each process or combination of processes, including variations, may be combined with any combination of storage media configured as described above and variations thereof.

[0114] More generally, those skilled in the art will recognize that not every part of this disclosure, or any specific detail therein, must satisfy legal standards such as enabling, written description, or best mode. Furthermore, embodiments are not limited to the specific motivating examples, programming languages or libraries or runtimes, software procedures, development tools, identifiers, data structures, data organization, notations, control flow, pseudocode, naming conventions, or other implementation choices described herein. Any apparent conflict with any other patent disclosure, even from the owner of the present invention, shall have no effect in interpreting the claims set forth in this patent disclosure.

[0115] Acronyms, abbreviations, names, and symbols

[0116] Some acronyms, abbreviations, names and symbols are defined below. Others are defined elsewhere herein or do not need to be defined herein in order to be understood by those skilled in the art.

[0117] ALU: Arithmetic and Logic Unit

[0118] API: Application Programming Interface

[0119] BIOS: Basic Input / Output System

[0120] CD: compact disc

[0121] CPU: Central Processing Unit

[0122] DVD: Digital Versatile Disc or Digital Video Disc

[0123] FPGA: Field Programmable Gate Array

[0124] FPU: Floating Point Processing Unit

[0125] GPU: Graphics Processing Unit

[0126] GUI: Graphical User Interface

[0127] IaaS or IaaS: Infrastructure as a Service

[0128] IOT: Internet of Things

[0129] LAN: Local Area Network

[0130] OS: operating system

[0131] PaaS or PAAS: Platform as a Service

[0132] RAM: Random Access Memory

[0133] ROM: Read-Only Memory

[0134] TPU: Tensor Processing Unit

[0135] UEFI: Unified Extensible Firmware Interface

[0136] WAN: Wide Area Network

[0137] Some additional terms

[0138] Reference is made herein to exemplary embodiments, such as those shown in the accompanying drawings, and specific language is used in the text to describe the same. However, changes and further modifications to the features shown herein, as well as additional technical applications of the abstract principles shown in the specific embodiments herein, which would occur to persons skilled in the relevant art and those having the benefit of this disclosure, should be considered within the scope of the claims.

[0139] The meaning of the terms is clarified in this disclosure, so these clarifications should be carefully noted when reading the claims. Specific examples are given, but those skilled in the relevant art will understand that other examples may also fall within the meaning of the terms used and fall within the scope of one or more claims. The meaning of the terms in this article is not necessarily the same as their meaning in general usage (especially non-technical usage), specific industry usage, specific dictionary or dictionary collection. Reference numbers can be used for various wordings to help show the breadth of the terms. Omitting reference numbers from a given text does not necessarily mean that the text does not discuss the content of the drawings. The inventor claims and exercises the right to compile specific and selected dictionaries. Referenced terms are explicitly defined, but terms can also be implicitly defined without using quotation marks. Terms can be defined explicitly or implicitly in the detailed description herein and / or elsewhere in the application documents.

[0140] As used herein, a "computer system" (also known as a "computing system") may include, for example, one or more servers, motherboards, processing nodes, laptop computers, tablet computers, personal computers (portable or non-portable), personal digital assistants, smartphones, smart watches, smart bracelets, mobile phones or mobile phones, other mobile devices having at least a processor and memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, and / or other devices that provide one or more processors controlled at least in part by instructions. The instructions may be in the form of firmware or other software in memory and / or dedicated circuitry.

[0141] A "multi-threaded" computer system is a computer system that supports multiple threads of execution. The term "thread" should be understood to include code that can or is subject to scheduling and possibly synchronization. Outside of this disclosure, threads may also be understood by aliases such as "tasks," "processes," or "co-routines." However, a distinction is made herein between threads and processes because threads define the execution path within a process. In addition, the threads of a process share a given address space, while different processes have different address spaces. The threads of a process can run in parallel, sequentially, or a combination of parallel and sequential execution (e.g., time slicing).

[0142] A "processor" is a thread-processing unit, such as the core in a simultaneous multithreading implementation. A processor comprises hardware. A given chip can house one or more processors. Processors can be general-purpose or customized for specific purposes, such as vector processing, graphics processing, signal processing, floating-point processing, encryption, I / O processing, machine learning, and so on.

[0143] The "kernel" includes the operating system, hypervisor, virtual machine, BIOS or UEFI code, and similar hardware interface software.

[0144] "Code" refers to processor instructions, data (including constants, variables, and data structures), or both. "Code" and "software" are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code.

[0145] "Program" is used broadly in this article to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (also called developers) and / or automatically generated.

[0146] A "routine" is a callable piece of code that typically returns control to the instruction after the point in program execution where the routine was called. A distinction is sometimes made between "functions" and "procedures" elsewhere, depending on the terminology used: functions typically return a value, while procedures do not. As used herein, "routine" includes both functions and procedures. A routine can have code that returns a value (e.g., sin(x)), or it can simply return without providing a value (e.g., a void function).

[0147] Regarding "reference objects" and "sub-objects," those skilled in the art will recognize that conventional references to objects can be explicitly declared in the source code, for example as pointer fields, and that dependent handles can also be explicitly declared in the source code. However, in some embodiments, the identification of these objects that are related in some way differs in terms of their purpose and their storage requirements. A conventional reference in object A that references another object involves allocating a field of the reference size in A that does not necessarily identify some other object B. Even if A never references some other object B, the code will always incur the storage overhead of this field in A. In contrast, a dependent handle establishes a relationship between object A and another object B (i.e., if A is active, then B is considered active). When there is an actual relationship between a particular object A and a particular object B, the dependent handle of object A only uses a field of the reference size to identify B.

[0148] The terms "reference", "address", "pointer", and "handle" are used in this article to discuss object identifiers in storage that are at least the size of a reference, i.e., they are at least N bits in an N-bit virtual address space. More importantly, each is larger than the IS-PRIMARY bit.

[0149] As used herein, "contains" is a broader term than "embeds" with respect to objects. "Contains" includes containment by reference, dependent handle, or contiguous allocation, while "embeds" requires contiguous allocation. Thus, if object A has a pointer to object B, then A contains B and the pointer is embedded in A, but B itself is not embedded in A. This distinction allows for (a) supporting dependent objects by embedding a reference-size field in each object in case they are used as primary objects, and (b) supporting dependent objects by embedding only a single bit (the IS-PRIMARY bit) and using a reference-size field only for objects that are actually primary objects (in the hash table).

[0150] "Cloud" refers to pooled resources for computing, storage, and networking that are elastically available for metered, on-demand services. Clouds can be private, public, community, or hybrid, and cloud services can be provided as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), or other services. Unless otherwise specified, any discussion of reading from or writing to a file includes reading / writing local files or reading / writing over a network, whether the network is a cloud network or another network, or both (local and network read / write).

[0151] "IoT" or "Internet of Things" refers to any networked collection of addressable embedded computing nodes. Such nodes are examples of computer systems as defined herein, but they also have at least two of the following characteristics: (a) no local human-readable display; (b) no local keyboard; (c) the primary source of input is a sensor that tracks non-verbal data sources; (d) no local rotating disk storage—RAM chips or ROM chips provide the only local storage; (e) no CD or DVD drive; (f) embedded in a household appliance or household fixture; (g) embedded in an implantable or wearable medical device; (h) embedded in a vehicle; (i) embedded in a process automation control system; or (j) a design focused on one of the following: environmental monitoring, municipal infrastructure monitoring, industrial equipment monitoring, energy usage monitoring, human or animal health monitoring, physical security, or physical transportation system monitoring. IoT storage can be a target for unauthorized access, whether via the cloud, via another network, or via direct local access attempts.

[0152] "Access" to a computing resource includes using permissions or other capabilities to read, modify, write, execute, or otherwise exploit the resource. A distinction can be made between attempted access and actual access, but "access" without the "attempt" qualifier includes both attempted access and actual access performed or provided.

[0153] As used herein, "comprising" allows for additional elements (ie, "comprising" means "including") unless stated otherwise.

[0154] "Optimization" means improvement, not necessarily perfection. For example, it is possible to further improve an already optimized program or algorithm.

[0155] "Process" is sometimes used in this article as a term in the field of computing science, in the technical sense, including computing resource users, which may also include or be called, for example, coroutines, threads, tasks, interrupt handlers, application processes, kernel processes, programs, or object methods. In practice, a "process" is composed of task manager, ps or similar utilities in other operating system environments (a mark of Microsoft Corporation, Linus Torvalds, respectively). "Process" is also used herein as a patent law term, for example, when describing a process claim as opposed to a system claim or an article of manufacture (configured storage medium) claim. Similarly, "method" is sometimes used herein as a technical term in the field of computer science (a "routine") and as a term in the field of patent law ("process"). "Process" and "method" in the patent law sense are used interchangeably herein. Those skilled in the art will understand the meaning in a particular case, and will also understand that a given claimed process or method (in the patent law sense) can sometimes be implemented using one or more processes or methods (in the computer science sense).

[0156] "Automatically" means through the use of automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein), as opposed to without automation. In particular, steps performed "automatically" are not performed manually on paper or in a person's mind, although they may be initiated by a human or directed by human interaction. Automatic steps are performed using a machine to achieve one or more technical effects that would not be achieved without the technical interaction so provided. Automatically performed steps are considered to include at least one actively performed operation.

[0157] Those skilled in the art understand that technical effects are the presumed purpose of the technical embodiments. For example, the embodiments involve calculations, and the fact that some of the calculations can also be performed without the technical components (e.g., with paper and pencil, or even as mental steps) does not remove the existence of the technical effects or change the specific and technical nature of the embodiments. Memory management operations such as marking objects, identifying reference objects, identifying sub-objects, and many other operations discussed herein are understood to be inherently digital operations. The human brain cannot directly interface with a CPU or other processor, or with RAM or other digital memory, to read and write the necessary data to perform the memory management steps taught herein. In view of this disclosure, those skilled in the art will understand all of this well.

[0158] "Computationally" also means using a computing device (at least a processor plus memory), and does not include results obtained solely through human thought or human action. For example, doing arithmetic with paper and pencil is not computationally performing arithmetic as understood herein. Computational results are faster, broader, deeper, more accurate, more consistent, more comprehensive, and / or otherwise provide a technical effect that is beyond the scope of human performance alone. A "computational step" is a step performed computationally. Neither "automatically" nor "computationally" necessarily means "immediately." "Computationally" and "automatically" are used interchangeably herein.

[0159] "Active" means without a direct request from the user. In fact, the user may not even be aware that an active step of an embodiment is possible until the results of that step are presented to the user. Unless otherwise noted, any calculation and / or automatic steps described herein may also be completed actively.

[0160] In this document, the optional plural "(s)" or "(es)" or "(ies)" is used to indicate the presence of one or more of the indicated features. For example, "a processor" means "one or more processors" or equivalently "at least one processor."

[0161] For purposes of U.S. law and practice, the use of the term "step" in the claims or elsewhere herein is not intended to invoke means-plus-function, step-plus-function, or 35 U.S.C. § 112(6) / § 112(f) claim construction. Any presumption to that effect is expressly rebutted.

[0162] For purposes of U.S. law and practice, a claim is not intended to invoke a means-plus-function interpretation unless the claim uses the phrase “means for.” Claim language, if any, that is intended to be interpreted as means-plus-function language will expressly state that intention by using the phrase “means for.” When means-plus-function interpretation is applicable, references to means in the specification for a given noun or a given verb should be understood to be connected to the claim language, by use of “means for” and / or by legal interpretation of the claim language by the courts, and are connected hereby by any of the following: appearance in the same block in a block diagram of the accompanying drawings, designation by the same or similar name, designation by the same figure numeral, a functional relationship depicted in any drawing, and a functional relationship mentioned in the text of this disclosure. For example, if a claim limitation recites a "zac widget" and that claim limitation is subject to a widget means-plus-function interpretation, then at least all structure identified anywhere in any figure, paragraph, or example in the specification that mentions "zac widget," or all structure associated together by any figure numerals assigned to the zac widget, or all structure disclosed as having a functional relationship to the structure or operation of the zac widget, will be considered part of the structure identified in an application of the zac widget and will help define an equivalent set of zac widget structures.

[0163] Those skilled in the art will recognize that the present disclosure discusses various data values and data structures, and recognizes that such items are located in memory (RAM, disk, etc.), thereby configuring the memory. Those skilled in the art will also recognize that the present disclosure discusses various algorithmic steps to be embodied in executable code in a given implementation, and that such code also resides in memory, and that it effectively configures any general-purpose processor that executes it, thereby converting it from a general-purpose processor into a special-purpose processor that is functionally special-purpose hardware.

[0164] Therefore, one skilled in the art would not be mistaken in regarding (a) the memory described in a claim and (b) the data structures or data values or code described in a claim as non-overlapping items. The data structures and data values and the code are understood to reside in the memory even when the claim does not expressly recite the residency of each data structure or data value or code segment mentioned. Therefore, an explicit recitation of such residency is not required. However, they are not prohibited, and one or two selected recitations may appear for emphasis without thereby excluding all other data values and data structures and code from residency. Similarly, the encoding function recited in the claims is understood to configure the processor, regardless of whether the configuration quality is explicitly recited in the claims.

[0165] In this document, unless otherwise explicitly stated, any reference to a step in a process assumes that the step can be performed directly by the relevant party and / or indirectly by that party through intervening mechanisms and / or intervening entities and still be within the scope of the step. That is, there is no requirement that the step be performed directly by the relevant party unless direct performance is an explicitly stated requirement. For example, steps involving actions by the relevant party, such as assigning, checking, clearing, embedding, enumerating, executing, following, instructing, looping, managing, marking, measuring, executing, providing, setting, specifying, replacing, processing, updating, or using (as well as assigning, being assigned, checking, being checked, etc.) may involve intervening actions, such as the aforementioned or forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, calling, etc., performed by some other party, including any actions recorded in this document, but are still understood to be performed directly by the relevant party.

[0166] Whenever reference is made to data or instructions, it should be understood that these items configure computer-readable memory and / or computer-readable storage media, thereby converting them into something specific, rather than simply existing on paper, in a person's mind, or as a signal propagating on, for example, a wire. In the United States, for purposes of patent protection, under the United States Patent and Trademark Office's (USPTO) interpretation of In re Nuijten, memory or other computer-readable storage media is not a propagating signal or carrier wave or simply energy beyond the scope of patentable subject matter. In the United States, no claim covers signals per se or simply energy, and any claim construction asserting the contrary is, on its face, unreasonable in light of this disclosure. Unless expressly stated otherwise in a claim issued outside the United States, the claim does not include signals per se or simply energy.

[0167] Furthermore, despite apparent content to the contrary elsewhere herein, a clear distinction should be understood between (a) computer-readable storage media and computer-readable memory, on the one hand, and (b) transmission media, also known as signal media, on the other hand. Transmission media are computer-readable media that propagate signals or carrier waves. In contrast, computer-readable storage media and computer-readable memory are not computer-readable media that propagate signals or carrier waves. Unless expressly stated otherwise in the claims, "computer-readable medium" refers to computer-readable storage media, not propagating signals per se, and not merely energy.

[0168] The "embodiments" herein are examples. The term "embodiments" is not interchangeable with "the invention." The embodiments may freely share or borrow aspects to create other embodiments (so long as the result is operable), even if the resulting combination of aspects is not itself explicitly described herein. Requiring that every permissible combination be explicitly and individually described is unnecessary for a person skilled in the art and would be contrary to the policy of recognizing that patent specifications are written for readers of skill in the art. Formal combinatorial calculations and informal common intuition about the number of possible combinations resulting from even a small number of combinable features will indicate that there are a large number of aspect combinations for the aspects described herein. Therefore, requiring that every combination be explicitly enumerated is contrary to the policy of requiring patent specifications to be concise and requiring the reader to understand the relevant art.

[0169] Reference Signs List

[0170] The following list is provided for the convenience and support of the drawings and as part of the specification text, which describes the innovation by reference to a number of items. Items not listed herein may still be part of a given embodiment. For better readability of the text, given reference numerals are cited near some, but not all, references to the referenced items in the text. The same reference numerals may be used to refer to different examples or different instances of a given item. The list of reference numerals is:

[0171] 100 Operating Environment, also known as Computing Environment

[0172] 102 Computer system, also known as computing system or computing system

[0173] 104 users, such as software developers

[0174] 106 peripheral devices

[0175] 108 Network, typically including LAN, WAN, software-defined network, cloud and other wired or wireless networks

[0176] 110 processor

[0177] 112 Computer-readable storage media, such as RAM, hard disk

[0178] 114 Removable configured computer readable storage medium

[0179] 116 Instructions executable by a processor; may be on a removable storage medium or in other memory (volatile or non-volatile or both)

[0180] 118 data

[0181] 120 cores, such as operating system, BIOS, UEFI, device drivers

[0182] 122 Tools, such as anti-virus software, firewalls, packet sniffer software, intrusion detection systems, intrusion prevention systems, other network security tools, debuggers, profilers, compilers, interpreters, decompilers, assemblers, disassemblers, source code editors, auto-completion software, simulators, fuzzers, repository access tools, version control tools, optimizers, collaboration tools, other software development tools and toolkits (including, for example, integrated development environments), hardware development tools and toolkits, diagnostics, etc.

[0183] 124 applications, such as word processors, web browsers, spreadsheets, games, email tools, commands

[0184] 126 Display screen, also known as "display"

[0185] 128 computing hardware not otherwise associated with reference numerals 106, 108, 110, 112, 114

[0186] A system enhanced with garbage collection memory management functionality, including some or all of functionality 202

[0187] 202 Any form of garbage collection memory management functionality described herein

[0188] 204 Garbage Collector, also known as "GC" or "Garbage Collector Code"

[0189] 206 GC threads, i.e., threads that are at least primarily (more than 50% of instructions) dedicated to garbage collector code

[0190] 208 mutator thread, i.e., a thread that is at least primarily (more than 50% of its instructions) dedicated to code other than garbage collector code; a mutator thread is typically a user thread, but can also be a kernel thread; the term "mutator" indicates that the mutator thread can mutate (i.e., change) addresses used during garbage collection

[0191] 210 Garbage Collector Marking Phase Code

[0192] 212 objects, such as object data structures allocated in a program implementing the object-oriented programming paradigm; for example, classes, structures, unions, members, fields, constructors, destructors,

[0193] 214 The heap portion of memory, often referred to simply as the "heap"

[0194] 216 Primary object, i.e., an object with at least one secondary object

[0195] 218 Secondary objects, i.e., objects that should be marked as active if their primary object is active; secondary objects are identified by mechanisms other than embedding their addresses in the reference fields of their primary objects, e.g., secondary objects can be identified in a hash table of primary-secondary relationships

[0196] 20 Non-primary objects, i.e., objects without secondary objects, which may or may not have any reference objects

[0197] 222 Active objects, that is, objects marked as active (still in use) by the garbage collector

[0198] 224 object reference, that is, a value embedded in an object that identifies another object; a reference may also be called a "pointer" or "object address" or "link" or "handle"; 224 also refers to a reference field; a reference field typically has at least as many bits as the address in any address space containing the referenced object, e.g., at least 32 bits in a 32-bit address space and at least 64 bits in a 64-bit address space, although the actual reference itself may be slightly smaller, e.g., 16 bits or 24 bits or 48 bits

[0199] 226 Floating garbage, such as memory that is not in use but has not yet been marked for recycling

[0200] 228 handle table

[0201] 230 Reachable memory, i.e., memory reachable through a heap root or other data structure connected to the allocated memory portion

[0202] 232 Unreachable memory, i.e., memory that cannot be reached

[0203] 234 Marked Memory

[0204] 236 unmarked memory

[0205] 238 Memory in use

[0206] 240 unused memory

[0207] 242 Code path overlap during execution; can be measured using one or more overlap metrics 244; numeral 242 also refers to the act of overlapping two or more code paths, such as by creating a program design and construction that performs overlap

[0208] 244 Code overlap metrics, such as the degree to which two (or more) code paths overlap in terms of lines of code, number of compiler-generated instructions, number of routines called, or number of stack frames

[0209] 246 Paths taken through the code during execution; in particular, 246-RO represents the reference object tag code path, and 246-SO represents the secondary object tag code path

[0210] 300 Memory segments, such as regions, pages, blocks, or other memory areas that are at least partially managed by garbage collection

[0211] 302 Allocated contiguous memory area that is in use or unknown to be reclaimable (in Figure 3 denoted by / in ), or is known to be reclaimable because the program that allocated it is known not to use it anymore (in Figure 3 (Indicated by X in the

[0212] 304 compression produces reproducible

[0213] 306 Compaction, such as relocating one or more reclaimable areas to create a larger contiguous reclaimable area

[0214] 308 Marking; Actions performed during garbage collection to mark a memory area as (i) in use or unknown reclaimable, or (ii) known reclaimable

[0215] 400 Typically, thread

[0216] Phases and sub-phases of 402 garbage collection

[0217] 404 garbage collection cleaning phase

[0218] The stop-the-world phase of a 406 garbage collection; also known as "STW"

[0219] 502 Referer

[0220] 504 Declaration or variable used to store object pointer

[0221] 506 Format information embedded in object-specific storage space

[0222] 602 represents a hash table or other data structure of the primary and secondary relationships; 602 also refers to the primary and secondary relationships

[0223] 604 Entry in data structure 602

[0224] 606 Slave handle, i.e., a handle that identifies the master-slave relationship between objects; a slave handle has a master object and a slave object associated with it, and associating two objects with the slave handle in this way forms a garbage collection relationship between the objects: if the master object is active, then the slave object will also be considered active.

[0225] 700 bits (i.e., storage locations with a capacity of one binary digit)

[0226] 702 is the IS-PRIMAY bit, that is, a bit whose value indicates whether the object embedded in the bit is a primary object.

[0227] 704 Space inside the object, dedicated to secondary object memory management; space 704 may include one or more bits, and in particular may include or consist of (depending on the implementation) the IS-PRIMARY bit 702; other bits may be included, for example to indicate the minimum generation of added references

[0228] 800 flow chart; 800 also refers to Figure 8 As shown in the flowchart or Figure 8 process Figure 1 consistent memory management methods

[0229] 802 Indicates whether the object is a primary object, for example by setting or clearing IS-PRIMARY 702

[0230] 804 Principality, such as whether the object is a primary object

[0231] 806 Set object activity

[0232] 808 uses integrated reference and sub-object tags; 808 also involves the integration of these types of tags

[0233] 810 executes in parallel

[0234] 812 Avoid embedding reference-sized space in each object just in case it happens to be the primary object

[0235] 814 Typically, garbage collection

[0236] 816 Embed bit variables or other data structures in objects

[0237] 900 flow chart; 900 also refers to Figure 9 Flowchart description or Figure 9 process Figure 1 consistent memory management approach (which combines Figure 8 Steps)

[0238] 902 For the purpose of mark 308, the secondary object is considered a reference object

[0239] 904 Following code path

[0240] 906 Check object activity

[0241] 908 Enumerate object references, addresses, or handles

[0242] 910 Receive command

[0243] 912Replacing one object with another

[0244] 914 Update data structure

[0245] 916 Avoid relying on looping through the entire table when listing 908 the objects for tagging, i.e., through the table containing both primary and non-primary objects

[0246] 918 Loop through the entire table (including the table of master objects and non-master objects)

[0247] 930 Avoid relying on boosting counters when enumerating 908 objects for tagging

[0248] 922 Advance counters, such as a counter for how many times an object is still to be marked as active, or a counter for how many times an object is still to be accessed during marking.

[0249] 924 sets the IS-PRIMARY bit to indicate that the object is a primary object

[0250] 926 Returns an object handle, for example as the return value of an object constructor

[0251] 928 specifies the secondary object, for example, in the data structure 602 representing the primary and secondary relationship

[0252] 930 Treat the secondary object as its own primary object

[0253] 932 Avoid imposing stop-the-world conditions

[0254] 934 Stop operation condition imposed

[0255] 936 Managing Memory in Computing Systems

[0256] 938 performs garbage collection as part of memory management

[0257] 940 is executed as part of a concurrent garbage collection

[0258] 942 provides at least one efficiency 944

[0259] 944 Efficiency, such as faster tagging, lower object storage requirements, and simpler code design

[0260] 946 Any step discussed in this disclosure without specifying another reference number

[0261] in conclusion

[0262] In short, the teachings herein provide various memory management functions 202 for computing systems 102 that enhance the performance of applications 124 using managed memory 112. Managing 936 secondary objects 218 effectively increases garbage collection concurrency 810 and reduces the storage requirements of objects 212. The activity flags 308 of secondary objects 218 are integrated 808 with the activity flags 308 of referencing objects 502. Allocating a reference-sized secondary object identifier field ( Figure 5 224 in); dedicated bits 702 designate a primary object 216. A primary object 216 is an object 212 that has at least one secondary object 218; if the primary object 216 is active, then the garbage collector 938 considers the secondary object 218 to be active 806. A secondary object 218 of a primary object X is typically not also a reference object 502 of the same primary object X. Any reference objects 502 of an active primary object 216 will also still be considered active 806. The code path 246-RO for marking 308 reference objects 502 can be shared with the code path 246-SO for marking 308 secondary objects 218 to allow for more efficient 944 secondary object marking 308. The primary-secondary object relationship 602 can be represented in a slave handle 606 and can be specified 928 in a hash table 602 or other data structure.

[0263] Embodiments should be understood to also include or benefit from tested appropriate security and privacy controls, such as the General Data Protection Regulation (GDPR), e.g., it should be understood that appropriate measures should be taken to help prevent the misuse of computing systems by injecting or activating malware into software. The use of the tools and techniques taught herein is compatible with the use of such controls.

[0264] Although Microsoft technologies are used in some of the motivational examples, the teachings herein are not limited to use with technologies provided or managed by Microsoft. For example, under appropriate licenses, the teachings herein may be embodied in software or services provided by other cloud service providers, other development environment providers, or other runtime providers.

[0265] Although specific embodiments are explicitly illustrated and described herein as processes, configured storage media, or systems, it will be understood that the discussion of one embodiment can generally extend to other types of embodiments as well. Figure 8 and Figure 9 The process descriptions of the present invention also help describe the configured storage medium and help describe the technical effects and operation of the system and manufacturing discussed in conjunction with the other figures. It does not follow that the limitations of one embodiment must be interpreted in another embodiment. In particular, the process is not necessarily limited to the data structures and arrangements presented when discussing systems or products such as configured memory.

[0266] Those skilled in the art will appreciate that implementation details may be relevant to specific code, such as specific thresholds, comparisons, sample fields, runtimes of specific types or programming languages or architectures, specific scripts or other tasks and specific computing environments, and therefore need not appear in each embodiment. Those skilled in the art will also appreciate that the program identifiers and some other terms used when discussing details are specific to implementation and therefore do not need to be relevant to each embodiment. Nevertheless, although not necessarily requiring them to appear in this article, these details may help some readers and / or may illustrate some of the many possible implementations of the technology discussed herein by providing context.

[0267] By paying due attention to the items provided herein, including the technical processes, technical effects, technical mechanisms and technical details of the embodiments that are illustrative but not comprehensive of all claimed or claimable embodiments, those skilled in the art will understand that the content of this disclosure and the embodiments described herein are not directed to subject matter outside the technical field, or any ideas themselves, such as main or original causes or motivations, or only results themselves, or mental processes or mental steps, or business methods or popular economic practices, or only methods of organizing human activities, or natural laws themselves, or naturally occurring things or processes, or organisms, or parts of organisms, or mathematical formulas themselves, or isolated software itself, or only conventional computers, or any completely imperceptible or any abstract concept itself, or insignificant post-solution activities, or any method implemented entirely on unspecified equipment, or any method that cannot produce useful and specific results, or any priority in all fields of use, or any other subject matter that is not eligible for patent protection under the laws of the jurisdiction in which patent protection is sought or granted or enforced.

[0268] Reference herein to an embodiment having some feature X and elsewhere herein to an embodiment having some feature Y does not exclude embodiments in the present disclosure having both feature X and feature Y, unless the exclusion is expressly stated herein. All possible negative claim limitations are within the scope of the present disclosure, in the sense that any feature stated as part of an embodiment may also be expressly removed from inclusion in another embodiment even if that specific exclusion is not given in any example herein. The term "embodiment" is used herein merely as a more convenient form of "process, system, article of manufacture, configured computer-readable storage medium, and / or other example of the teachings herein, applied in a manner consistent with applicable law." Thus, a given "embodiment" may include any combination of the features disclosed herein, as long as the embodiment is consistent with at least one claim.

[0269] Not every item shown in the figures needs to appear in every embodiment. Conversely, an embodiment may include items that are not explicitly shown in the figures. Although some possibilities are shown herein and in the figures by specific examples, the embodiments may deviate from these examples. For example, specific technical effects or technical features of the examples may be omitted, renamed, grouped differently, repeated, instantiated differently in hardware and / or software, or be a mixture of effects or features that appear in two or more examples. In some embodiments, a function shown in one location may also be provided in a different location; those skilled in the art recognize that in a given implementation, functional modules may be defined in various ways without omitting the desired technical effect from the set of interacting modules as a whole. Due to space limitations or for convenience, different steps may be shown together in a single box in the figure, but may still be performed separately, for example, in a given execution of the method, one step may be performed without another step.

[0270] Reference is made to the accompanying drawings by reference numerals. Any apparent inconsistency in the wording associated with a given reference numeral in the drawings or text should be understood as simply widening the scope of the reference to that numeral. Different instances of a given reference numeral may refer to different embodiments, even when the same reference numeral is used. Similarly, a given reference numeral may be used to refer to a verb, a noun, and / or corresponding instances of each, e.g., processor 110 may process 110 instructions by executing instructions.

[0271] As used herein, terms such as "a," "an," and "the" include one or more of the specified items or steps. In particular, in the claims, reference to an item generally implies the presence of at least one such item, and reference to a step generally implies at least one instance of performing that step. Similarly, when the context permits, "is" and other singular verb forms should be understood to encompass the possibility of "are" and other plural forms to avoid grammatical errors or misunderstandings.

[0272] Headings are for convenience only; information about a given topic may be found outside the section whose heading indicates that topic.

[0273] All claims and the abstract as filed are part of the specification.

[0274] To the extent that any term used herein refers to or otherwise refers to an industry standard, and to the extent applicable law requires identification of a particular version of such a standard, this disclosure should be understood to refer to the most recent version of that standard published under applicable patent law in at least draft form (or, if more recent, in final form) as of the earliest priority date of this disclosure.

[0275] Although exemplary embodiments have been shown in the drawings and described above, it will be understood by those skilled in the art that various modifications may be made without departing from the principles and concepts set forth in the claims, and that such modifications need not encompass the entire abstract concept. Although the subject matter has been described in language specific to structural features and / or procedural actions, it will be understood that the subject matter defined in the appended claims is not necessarily limited to the specific technical features or actions described in the claims. It is not necessary for every means or aspect or technical effect identified in a given definition or example to appear or be used in every embodiment. Instead, the specific features, actions, and effects described are disclosed as examples to be considered when implementing the claims.

[0276] To the maximum extent permitted by law, all changes that do not encompass the entire abstract concept but come within the meaning and range of equivalency of the claims are embraced within their scope.

Claims

1. A system configured to use secondary objects for memory management, the system comprising: Memory; a processor in operable communication with the memory, the processor configured to perform steps for memory management, the steps comprising: (a) indicating in dedicated spaces embedded in a plurality of objects whether a corresponding object in the plurality of objects is a primary object, each dedicated space being smaller than an object reference, a primary object being an object having at least one secondary object, the at least one secondary object being considered active by garbage collection if the primary object is active, rather than a reference object of the primary object; and (b) during garbage collection marking, treating the secondary objects as reference objects by at least marking (i) all reference objects of each active object X and (ii) all secondary objects of each active object X as active; The system integrates marking of reference objects with marking of secondary objects during garbage collection to recover memory for further use without requiring objects that are not primary objects to be embedded in a reference-sized space to hold references to secondary objects.

2. The system of claim 1, further comprising a hash table having an entry, wherein the hash table entry comprises a primary object reference to a primary object and a secondary object reference to a secondary object, thereby indicating that the secondary object is a secondary object of the primary object. 3 . The system of claim 1 , wherein each dedicated space embedded in an object for indicating whether the object is a primary object consists of a single bit.

4. The system of claim 1, wherein the object comprises a primary object Y having at least two secondary objects. 5 . The system of claim 1 , wherein the objects include an object Z that is not a primary object, and wherein the object Z has no secondary objects and no embedded references.

6. The system of claim 1, wherein the object includes a secondary object Q, which is also a primary object.

7. The system according to claim 1, further characterized in that At least one of the following: at most ten percent of the objects of a program at least partially executed in the system are master objects; or A program executed at least partially in the system has at least ten thousand objects, each object X of the at least ten thousand objects having a corresponding embedded private space of no more than four bits to indicate whether the object X is a primary object, and each object X of the at least ten thousand objects lacking any embedded private space of greater than four bits to identify any other object as a secondary object of the object X.

8. A method of memory management using a secondary object, the method comprising automatically: indicating, in dedicated spaces embedded in a plurality of objects, whether a corresponding object in the plurality of objects is a primary object, each dedicated space being smaller than an object reference, a primary object being an object having at least one secondary object, the at least one secondary object being considered active by garbage collection if the primary object is active, rather than being a referenced object of the primary object; During garbage collection marking, treating secondary objects as referenced objects by marking at least (i) all referenced objects of each live object X and (ii) all secondary objects of each live object X as live; and Avoid embedding any reference-sized space in objects that are not primary objects to hold references to secondary objects.

9. The method of claim 8, further comprising at least one of the following during garbage collection marking: Follow the code path shared by the secondary object marking and the referenced object marking, at least to the point where each object is checked for liveness; or The code path shared by secondary object marking and reference object marking is followed, at least to the point where object references are enumerated to support checking the liveness of individual objects.

10. The method of claim 8, further comprising at least one of the following during garbage collection marking: Avoid relying on looping through a table of handles that includes non-primary objects to collect secondary object handles; or Avoid relying on liveness increment counter values to collect secondary object handles.

11. The method of claim 8, further comprising setting a bit embedded in an object to indicate that the object is a master object before returning a handle to the object as a result of a request to create the object.

12. The method of claim 8, further comprising using a hash table to designate that an object is a secondary object of a primary object.

13. The method according to claim 8, further comprising: A data structure is used to specify that Object X and Object Y are each secondary objects of a primary object.

14. The method of claim 8, further comprising receiving a command to replace at least one object of a particular primary-secondary relationship, and updating a data structure specifying the primary-secondary relationship when the command is executed.

15. The method according to claim 8, further comprising: Treat secondary object X as its own primary object by labeling each reference object in object X and labeling each secondary object in object X.

16. A computer-readable storage medium configured with data and instructions that, when executed by a processor, cause a computing system to perform a method for memory management using secondary objects, the method comprising: indicating, in dedicated spaces embedded in a plurality of objects, whether a corresponding object in the plurality of objects is a primary object, each dedicated space being smaller than an object reference, a primary object being an object having at least one secondary object, the at least one secondary object being considered active by garbage collection if the primary object is active, rather than being a referenced object of the primary object; During garbage collection marking, treating secondary objects as referenced objects by marking at least (i) all referenced objects of each live object X and (ii) all secondary objects of each live object X as live; and Avoid embedding any reference-sized spaces in objects other than the primary object to hold references to secondary objects. Each reference-sized space is at least 32 bits in size.

17. The computer-readable storage medium of claim 16, wherein the method comprises: Following a referenced object marking code path to mark referenced objects during garbage collection, and including following a secondary object marking code path to mark secondary objects during the garbage collection, and wherein at least fifty percent of the referenced object marking code path overlaps with the secondary object marking code path under at least one of the following overlap metrics: number of lines of code, number of instructions generated by the compiler, number of routines called, or number of stack frames, whether including library code or excluding library code or both, and whether along all executed paths or all possible paths or only shortest paths.

18. The computer-readable storage medium of claim 16, wherein the method avoids imposing a stop-the-world condition by performing garbage collection marking of secondary objects concurrently with execution of the application program.

19. The computer-readable storage medium of claim 16, wherein the method is performed as part of a concurrent garbage collection.

20. The computer-readable storage medium of claim 16, wherein the method avoids relying on looping through any handle data structure that includes handles to both primary and non-primary objects to collect secondary object handles for marking.

Images