Integrated reference and secondary marking

Abstract

Efficiently managing secondary objects increases garbage collection concurrency and reduces object storage requirements. Liveness marking of secondary objects is integrated with liveness marking of referencing objects. Allocating a reference-sized secondary object identifier field in objects that are not primary objects is avoided, and a dedicated bit designates the primary object along with a table of object relationships. A primary object is an object that has at least one secondary object that is considered live by garbage collection if the primary object is live, even if it is not a reference object of the primary object. Any referencing objects of a live primary object are still considered live. To enable more efficient marking of secondary objects, the code path for marking referencing objects may be shared. The primary-secondary object relationship may be represented by a dependency handle, which may be specified in a hash table or other data structure.

Description

[Background technology]

[0001] background

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

[0002]

[0002] Garbage collection eliminates the need for programmers to manually free data objects that are no longer needed, and can therefore make programming easier. Garbage collection can also help prevent some runtime errors, thereby enhancing cybersecurity by improving data integrity and availability. Many programming languages ​​or runtimes 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]

[0003] Because garbage collectors may run frequently or at unpredictable times or both, which can significantly slow down the execution of user programs, an efficient implementation of garbage collection can be a high priority. In fact, most, if not all, garbage collectors may utilize a "stop-the-world" technique that prevents user programs from running at the same time as the garbage collector. One can imagine configuring the garbage collector to run less frequently or giving the garbage collector less time to complete its work. However, simply reducing the time spent on garbage collection without simultaneously increasing the efficiency of the garbage collection can also reduce the amount of memory reclaimed, which can hinder the performance of user programs, for example, by spending more time swapping data between volatile and non-volatile memory devices or by using up available memory more quickly. Summary of the Invention

[0004] overview

[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 reference objects of their primary objects, if their respective primary objects are live. Some embodiments integrate the liveness marking of reference objects with the liveness marking of secondary objects. In particular, code space and complexity are reduced, in part by duplicating code paths for each type of marking, and execution time is reduced. 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 have no secondary. Other efficiencies can also be achieved.

[0005]

[0005] Some embodiments configured for memory management using secondary objects assume or provide a private space embedded in multiple objects. Each private space indicates whether the embedded object in that space is a primary object. Each private space is smaller than an object reference, and 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 that is considered live by garbage collection if the primary object is live, even if it is not a reference object of the primary object. Any reference object that is primary is considered live. During garbage collection marking, some embodiments treat secondary objects as reference objects by marking as live at least both (i) all reference objects of each live object X, and (ii) all secondary objects of each live object X. A reference object Y of an object X is the object that X points to in X's declared embedded field.

[0006]

[0006] Other technical activities and characteristics related to the teachings of this specification will be apparent to those skilled in the art. The examples shown are illustrative only. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Rather, this summary is provided to introduce in a simplified form some technical concepts that are further described below in the detailed description. The technical innovation is defined by the claims, as properly understood, and the claims shall take precedence only to the extent that this summary conflicts with the claims.

[0007] Description of the drawings

[0007] A more particular description will now be made with reference to the accompanying drawings, which merely illustrate selected aspects and therefore do not fully determine scope or extent. [Brief description of the drawings]

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

[0009] 1 is a block diagram illustrating some aspects of a computer system having enhanced memory management capabilities. [Diagram 3]

[0010] FIG. 2 illustrates aspects of the memory state at various times during garbage collection. [Figure 4]

[0011] FIG. 2 illustrates concurrent execution of garbage collection threads and mutator threads. [Diagram 5]

[0012] FIG. 2 illustrates primary objects, secondary objects, and object references. [Figure 6]

[0013] FIG. 2 illustrates a hash table that represents first-order-second-order relationships between objects. [Figure 7]

[0014] FIG. 2 illustrates a bit in an object instance data structure. [Figure 8]

[0015] 1 is a flow diagram illustrating steps in some memory management methods. [Figure 9]

[0016] 4 is a flow chart further illustrating steps in some memory management methods. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Detailed Description

[0017] overview

[0018] Although an innovation may extend beyond its origin, understanding the origin of an innovation may help to understand the innovation more fully. In this case, some of the teachings described herein were motivated by technical challenges faced by innovators at Microsoft who were working to improve the performance of concurrent or non-concurrent garbage collection with secondary objects. The innovators conducted a performance study of concurrent garbage collection mechanisms with secondary objects. This performance study was preliminary, and was in fact conducted with the goal of enabling the creation of secondary objects directly through a public API at some later point in time.

[0010]

[0019] In some environments where garbage collection is performed, objects may contain extended references, for example by using a dependent GC handle type. A dependent handle has a primary object and a secondary object, and the secondary only lives if the primary lives (unless kept alive by something else). This imposes complexity on marking in some implementations, since information for the primary does not know about the secondary.

[0011]

[0020] Such secondary objects are relatively rare because they are only used internally or in other ways that are largely or completely hidden from public API access. Where use of secondary objects increases as a result of making the creation of dependency handles part of the public API, the teachings provided herein enable efficient scaling of garbage collection of secondary objects in ways that well-known garbage collection techniques do not provide.

[0012]

[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 primary-secondary relationships in an efficient and scalable manner. One approach is to keep the secondary object handles listed in a handle table that contains a primary object handle, a secondary object handle, and a non-primary object handle. A non-primary object is an object that has space to contain a secondary object handle (and thus is a primary of its secondaries), but is not actually a primary object (i.e. does not actually have any secondaries).

[0013]

[0022] However, this handle table approach is inefficient because it involves looping through many non-primary objects to collect secondary object handles during garbage collection. Furthermore, this approach does not scale well as non-primary objects are added because adding non-primary objects increases the work done to collect secondary object handles. Storing space for secondary object handles within every object is also inefficient because in many cases the space is never utilized.

[0014]

[0023] Some embodiments taught herein build a mapping between a primary and all its secondaries, for example in a hash table, a balanced tree, or another data structure. Entries for non-primary objects do not need to appear in the mapping data structure, which helps make this mapping data structure more efficient than a traditional handle table as far as identifying secondary objects is concerned.

[0015]

[0024] Some embodiments include automatically marking in garbage collection both the references an object contains and any secondaries it may have, some further aiding efficiency by sharing important code paths for both types of marking.

[0016]

[0025] In addition, some embodiments embed an IS-PRIMARY bit in the object, which is set to indicate that the object is primary, and thus has one or more secondaries, e.g., the secondaries identified in the mapping discussed above. The IS-PRIMARY bit is cleared to indicate a non-primary object, i.e., an object that has no secondaries. These embodiments thus avoid allocating an extra slot in each object, as some less space-efficient approaches do.

[0017]

[0026] These are just examples. Other aspects of these embodiments, as well as other embodiments of memory management, are also described herein.

[0018]

[0027] Operating environment

[0028] With reference to FIG. 1, an operating environment 100 for one embodiment includes at least one computer system 102. The computer system 102 may or may not be a multiprocessor computer system. The operating environment may include one or more machines within a given computer system, and such machines may be clustered in a cloud, client-server networked, and / or peer-to-peer networked. An individual machine is a computer system, and a group of machines working together is also a computer system. A given computer system 102 may be configured, for example, with applications, for end users, for administrators, as a server, as a distributed processing node, and / or in other ways.

[0019]

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

[0020]

[0030] System administrators, network administrators, cloud administrators, security analysts and other security personnel, operations personnel, developers, testers, engineers, auditors, and end users are each particular types of users 104. Automated agents, scripts, playback software, devices, etc. operating on behalf of one or more humans may also be users 104, for example to help test system 102. Depending on their separability from processor 110, storage devices and / or networking devices may be considered peripherals in some embodiments and part of system 102 in other embodiments. Other computer systems not shown in FIG. 1 may technically interact with computer system 102 or another system embodiment, for example, using one or more connections to network 108 via network interface devices.

[0021]

[0031] Each computer system 102 includes at least one processor 110. The computer system 102, like other suitable systems, also includes one or more computer-readable storage media 112. The storage media 112 can be of various physical types. The storage media 112 can be volatile memory, non-volatile memory, fixed-position media, removable media, magnetic media, optical media, solid-state media, and / or other types of physically persistent storage media (as opposed to merely a propagating signal or merely energy). In particular, configured storage media 114, such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile memory media, can functionally become a technical part of the computer system upon insertion or installation, making its contents accessible for interaction with and use by the processor 110. The removable configured storage media 114 is one example of a computer-readable storage medium 112. Some other examples of computer readable storage medium 112 include built-in RAM, ROM, hard disks, and other memory storage devices that are not easily removable by user 104. To comply with current U.S. patent requirements, under any claim pending or granted in the United States, neither computer readable medium nor computer readable storage medium nor computer readable memory is itself a signal or mere energy.

[0022]

[0032] The storage medium 114 is configured by the processor 110 with binary instructions 116 that are executable files, and "executable files" is used broadly herein to include, for example, machine code, interpretable code, bytecode, and / or code executed on a virtual machine. The storage medium 114 is also configured with data 118 that is created, modified, referenced, and / or otherwise used for the technical effect of executing the instructions 116. The instructions 116 and data 118 constitute a memory or other storage medium 114, and if that memory or other computer-readable storage medium is a functional part of a given computer system, then the instructions 116 and data 118 also constitute that computer system. In some embodiments, some of the data 118 represent real-world items such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, and the like. Such data may also be transformed by backing up, restoring, committing, aborting, reformatting, and / or other technical operations.

[0023]

[0033] Although an embodiment may be described as being implemented as software instructions executed by one or more processors in a computing device (e.g., a general purpose computer, server, or cluster), such description is not intended to be exhaustive of all possible embodiments. Those skilled in the art will appreciate that the same or similar functionality may often be implemented directly in hardware logic, in whole or in part, to produce the same or similar technical effect. Alternatively, or in addition to a software implementation, the technical functionality described herein may be performed at least in part by one or more hardware logic components. For example, and without excluding other implementation forms, 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. The components of an embodiment may be grouped into interacting functional modules, for example, based on their inputs, outputs, and / or their technical effect.

[0024]

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

[0025]

[0035] In some embodiments, the system includes multiple computers connected by wired and / or wireless network 108. The networking interface equipment 128 may provide access to the network 108 using network components such as packet-switched network interface cards, wireless transceivers, or telephone network interfaces that may be present in a given computer system. Virtualization of the networking interface equipment and other network components such as switches or routers or firewalls may also be present, for example, in a software-defined network or a sandboxed or other secure cloud computing environment. In some embodiments, one or more computers are partially or completely "air-gapped" because they are disconnected or only intermittently connected to another networked device or a remote cloud. In particular, memory management functions taught herein may be deployed on air-gapped systems and updated periodically or occasionally using removable media. A given embodiment may also communicate technical data and / or technical instructions by direct memory access, removable non-volatile storage media, or other information storage-retrieval and / or transmission techniques.

[0026]

[0036] Those skilled in the art will appreciate that these and other aspects presented herein under "Operating Environment" may form part of a given embodiment. The headings herein are not intended to strictly classify features into feature sets of embodiments and non-embodiments.

[0027]

[0037] One or more items are shown in the figures in dashed outline form or listed in parentheses to emphasize that, although not necessarily a part of the illustrated operating environment or all embodiments, they may interoperate with items in the operating environment or some embodiments discussed herein. No item that is not in a dashed outline or in parenthetical form is required to be in any figure or in any embodiment. In particular, Figure 1 is shown for convenience, and the inclusion of an item in Figure 1 does not imply that the item or the use of the described item was known prior to the current technological innovation.

[0028]

[0038] Further information about the system

[0039] 2 illustrates some aspects of a system 200 that is a system 102 enhanced with at least some of the features 202 taught herein for memory management involving secondary objects. Specifically, the enhanced system 200 illustrated includes a garbage collector (GC) 204 that is introduced within a GC thread 206 or in the GC marking phase code 210 or another location. The enhanced GC has at least one of the following properties: the GC unifies the marking of references with the marking of secondary objects, the GC avoids relying on reference size fields embedded in objects to indicate whether the object is a primary object, or the GC avoids looping on non-primary object handles to collect secondary object handles. These features 202 properties aid in memory efficiency 944 by reducing the storage requirements for objects in both concurrent and non-concurrent garbage collections, and aid in computational efficiency 944 by reducing the computational requirements and computational complexity of GC marking.

[0029]

[0040] In many cases, mutator threads 208 may be user threads, i.e., threads that run in a user address space, but the same tools and techniques taught herein can be applied to garbage collection performed on threads that run in the kernel address space.

[0030]

[0041] The memory 112 of the illustrated system 200 includes a number of objects 212, such as objects allocated in a heap 214. As illustrated, the objects 212 may be primary objects 216 with one or more secondary objects 218, or the objects may be non-primary objects 220. A secondary object Y of a primary object X may itself be a primary object, in that Y may have its own secondary Z. Each of the primary objects, secondary objects, and non-primary objects may or may not be live 222. Regardless of any primary-secondary relationship or lack thereof, each of the primary objects, secondary objects, and non-primary objects may have zero or more references 224 to other objects. Handles 224 of (at least) the non-primary objects may be maintained in a handle table 228. The handle table 228 may be implemented using aspects of a data structure such as an array, a tree, an index, a hash, or a pointer.

[0031]

[0042] 2, objects 212 and other parts of memory 112 may be reachable (230) or unreachable (232) during the marking phase of garbage collection, may be marked (234) or unmarked (236) during the marking phase of GC, and may be in use (238) by software other than the GC or unused by such software (240). Memory that is unused but not yet identified as available for reclaim may be considered floating garbage 226.

[0032]

[0043] As mentioned above, enhanced functionality 202 may include consolidating the marking of reference objects with the marking of secondary objects. Such consolidation may be implemented by a shared code path for both types of marking. Thus, FIG. 2 also shows code paths 246, and metrics 244 for measuring the degree of any overlap 242 (sharing) of the code paths. However, consolidation may also be evident in the lack of detail required to cause the marking. In some embodiments, a caller to a top-level GC marking routine simply asks that the marking routine obtain references and mark them, without the details of an explicit request for the marking of dependent handles. With such consolidation code, the caller does not need to know about the marking of dependent handles or other secondary markings, and secondary markings do not require special handling except when at the level of individual objects.

[0033]

[0044] 3 and 4 further illustrate some aspects of garbage collection, some of which are well known or occur within well known garbage collection activities, but whose relevance to the teachings herein becomes apparent only after understanding the innovative garbage collection markings.

[0034]

[0045] As shown in Figure 3, garbage collection code operates on a segment 300 of memory 112 that is divided into contiguous regions 302 by program execution. A given region 302 may be explicitly in use by one or more mutator threads and therefore unavailable for reuse, as indicated by a checkmark symbol in Figure 3. A given region 302 may not be explicitly in use and therefore available for reuse, as indicated by an X in Figure 3. The reusability of a region 302 may also be pending.

[0035]

[0046] Garbage collection generally involves tracing addresses or determining the used or unused state of memory regions and marking (308) the memory regions (or data structures representing the regions) accordingly. Some garbage collectors leave the marked regions where they are found, and memory from the reusable region is allocated to programs 120, 122, 124. This technique is used in so-called mark-sweep garbage collection algorithms. Other garbage collectors rearrange used regions to compact together 306 regions with the same reusability state, or rearrange reusable regions, or do both. This technique, known as mark compaction, often results in a larger reusable region 304 than the mark-sweep technique, but is complicated by the requirement to properly update addresses to match the results of the compaction.

[0036]

[0047] 3 and 4 help illustrate the garbage collection phases or sub-phases 402 and their relationship to concurrency when there is some concurrency. These figures show some specific phases in a garbage collection cycle, including a marking phase 308, a sweeping phase 404, and a compacting phase 306. During marking 308, reachable objects 230 or other non-reusable areas of memory are marked at the same location or in a data structure that represents them. During sweeping 404, reusable objects are cleared from the heap 214, for example by being placed in a pool for reallocation. During compaction 306, reusable areas are placed together, which may also be viewed as placing used areas together. A given garbage collector does not necessarily perform each phase, for example compaction 306 may be omitted.

[0037]

[0048] A simple approach to garbage collection would be to simply suspend everything except the garbage collector while it marks 308 the memory region as in use or available for reuse. However, such a drastic "stop-the-world" approach would degrade the performance of user programs too severely to be tolerated in most systems. Thus, garbage collectors can be designed with the goal of limiting long "stop-the-world" sub-phases 406 by allowing concurrent execution of the garbage collection thread 206 and any mutator threads 208. The marking phase can be subdivided into concurrent and non-concurrent portions. Using function 202 tends to increase concurrency during marking, and thus improve the performance of user code that is subject to garbage collection. Concurrency involves at least two threads overlapping in execution at least part of the time, but does not require that both threads always start together or suspend together or stop together.

[0038]

[0049] Figure 5 further illustrates object 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. Figure 5 thus illustrates two references 224: a reference in pointer variable 504 that references object A, and a reference in object A that references object B.

[0039]

[0050] In this example, format information 506 is also embedded within object A. Format information structure 506 may indicate, for example, the types and offsets of fields or other members of object A. Although FIG. 5 has an arrow pointing to one end of a given object suggesting that the address used to identify the object is the first byte of the object, one skilled in the art will appreciate that in practice an object-oriented programming implementation may use an address that identifies a non-zero offset into region 302 allocated to the object. For example, the address may point to a byte following a predefined header section 506 that contains format information or other metadata. The teachings herein may be adapted accordingly by one skilled in the art.

[0040]

[0051] FIG. 6 illustrates a hash table 602 that represents primary-secondary relationships. In this example, each primary-secondary relationship is part of a dependency handle 606. In this example, each dependency handle 606 has its own entry in the hash table 602, and the entries are organized according to the hash code of the primary object. In the illustrated portion of the table 602, a first entry indicates that object C is a secondary of object A, and a second entry indicates that object D is a secondary of object C. Some embodiments hash on the addresses of the primary objects and combine the handles so that a query on a primary object can quickly provide all the secondaries of its queried primary. In a compacting garbage collector, the addresses of some primary objects may change, after which those addresses are hashed again. More generally, in some embodiments, handles are used to track primary-secondary object relationships instead of using a dedicated reference-sized space in every object that can be a primary object.

[0041]

[0052] 7 illustrates memory configured as object format information portion 506, including bits 700 that may be used to indicate, for example, the data type and size or offset of each member of the object. In accordance with the teachings herein, the well-known instance format information may be enhanced to include an IS-PRIMARY bit 702 that indicates whether the object is a primary object. If the object is primary, then one or more secondaries of the object are identified, for example, in hash table 602. The location of IS-PRIMARY bit 702 in FIG. 7 is illustrative and not normative.

[0042]

[0053] Some embodiments provide the advantage of being able to use secondary objects without requiring every object to reserve space large enough to hold a reference (942) as some other approaches do. This embodiment reserves one bit per object (the IS-PRIMARY bit) plus space for the actual primary and secondary object identifiers. This saves space when objects 212 proliferate. The runtime environment 100 may have some spare bits 700 available for such things, so implementing such a bit 702 would not necessarily be very disruptive to an existing runtime code base once the teachings herein are understood.

[0043]

[0054] Another advantage of some embodiments is that the marking of secondary objects is integrated with the marking of reference objects, with relatively little disruption to existing GC code, and leveraging the existing code for marking 210 by making it also work differently.

[0044]

[0055] Specifically, some embodiments use or provide a secondary object memory management enhancement system, such as system 200 or another system 102, configured for memory management 936 using secondary objects 218 as taught herein. Enhancement system 200 includes memory 112 and processor 110 in operative communication with the memory. Processor 110 is configured to perform memory management steps including (a) indicating whether each of a plurality of objects is a primary object 216 within a dedicated space 704 embedded within a plurality of objects 212, each dedicated space being smaller than an object reference 224, a primary object being an object having at least one secondary object 218, and a secondary object being considered live by garbage collection if the primary object is live even if it is not a reference object of the primary object, and (b) treating secondary objects 218 as reference objects 502 during garbage collection marking by marking at least both (i) all reference objects of each live object X, and (ii) all secondary objects of each live object X as live. The enhancement system 200 merges the marking of reference objects with the marking of secondary objects during garbage collection to recover memory for further use without requiring non-primary objects 220 to pad reference-sized space for holding references to secondary objects.

[0045]

[0056] Some embodiments further include a hash table 602 having entries 604. Each hash table entry includes a primary object reference 224 to the primary object 216 and a secondary object reference 224 to the secondary object 218, thereby indicating that the secondary object is a secondary object of the primary object. In other embodiments, the primary-secondary relationship is represented using other data structures. Regardless of the particular data structure used, such a representation can be advantageously limited to only those objects actually involved in the primary-secondary relationship, unlike inefficient approaches that proactively allocate space in every object in case the object acts as a primary object.

[0046]

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

[0047]

[0058] Regardless of labeling, embodiments can avoid the inefficiency of a dedicated secondary reference space in every object. Doing so saves space even when non-primary objects have references 224 to reference objects 502. Specifically, in some embodiments, objects 212 include object Z 220, which is not a primary object, and object Z has no secondary objects and does not embed references.

[0048]

[0059] In some embodiments, a primary has multiple secondaries. Thus, in some embodiments, object 212 includes a primary object Y 216 that has at least two secondary objects 218.

[0049]

[0060] In some embodiments, the secondary may itself be a primary. Thus, in some cases, object 212 contains a secondary object Q 218 that is also a primary object 216.

[0050]

[0061] An operational scenario helps illustrate the space saving benefits of some embodiments. In some cases, up to 10 percent of the objects 212 of a program at least partially executed within the enhanced system 200 are primary objects 216. Thus, using only one bit 702 to indicate non-primary instead of using a null reference size field such as a pointer field contributes at least 90 percent to efficiency 944. This savings may be offset somewhat by the storage required for a hash table or other primary-secondary relationship representation data structure 602, but using one bit in every object instead of a pointer in every object ultimately saves space. Those skilled in the art will appreciate that this 10 percent upper limit is merely an example of a ratio that may be met in some situations, and is not an absolute requirement for all embodiments.

[0051]

[0062] In some scenarios, a program executed at least partially within the enhanced system 200 has at least 10,000 objects 212, where each object X has an individual embedded dedicated space 704 of no more than 4 bits to indicate whether object X is a primary object. Each object X further does not have any embedded dedicated space of more than 4 bits to identify any other object as a secondary object of object X.

[0052]

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

[0053]

[0064] Although specific architecture examples are shown in the figures, embodiments may deviate from those examples: for example, items shown in various figures may be included together in an embodiment, items shown in certain figures may be omitted, functionality shown in various items may be combined into fewer items or into a single item, items may be renamed, or items may be connected differently to one another.

[0054]

[0065] Although examples have been provided in this disclosure to help illustrate aspects of the technology, the examples provided herein do not describe all possible embodiments, and a given embodiment may, for example, include additional or different technical features, mechanisms, sequences, data structures, or functions, or may deviate from the examples provided herein.

[0055]

[0066] Process (also called method)

[0067] FIG. 8 illustrates methods 800 that may be performed or supported by an enhancement system such as system 200 or another enhancement system taught herein. FIG. 9 further illustrates a memory management method (which may be legally referred to as a "process") suitable for use during operation of a system having the innovative features taught herein. FIG. 9 includes some refinements, supplements, or contextual actions with respect to the steps illustrated in FIG. 8. FIG. 9 also incorporates the steps illustrated in FIG. 8. Unless otherwise specified, the technical process illustrated or disclosed in the figures is performed automatically, for example, by garbage collection code that reads space 704 and by object constructor code that initializes space 704. To the extent that action by a human administrator or other person is involved, the process may be partially automatic and partially manual, for example, in some embodiments a developer may specify the relative frequency of garbage collection periods. No process considered innovative herein is fully manual. In a given embodiment, zero or more illustrated steps of the process may be repeated, possibly with different parameters or data acting upon. Steps of the embodiments may occur in an order different from the top-down order shown in Figures 8 and 9. Steps may be performed sequentially, partially overlapping, or fully parallel. In particular, the order in which the action items of control flow diagram 800 or the action items of control flow diagram 900 are traversed to indicate steps performed during a process may vary from one implementation of the process to another. The order of traversal of the charts may vary from one implementation of the process to another. Steps may be omitted, combined, renamed, regrouped, performed on one or more machines, or deviated from the illustrated flow, provided that the process performed is operable and in accordance with at least one claim.

[0056]

[0068] Some embodiments use or provide a method for computing system memory management 936 using secondary objects, the method including the automated steps of indicating (802) whether each of a plurality of objects is a primary object (804) in a dedicated space 704 embedded within the plurality of objects, where each dedicated space is smaller than an object reference, the primary object is an object that has at least one secondary object, and the secondary object is considered live by garbage collection if the primary object is live even if it is not a reference object of the primary object; treating the secondary objects as reference objects (902) by marking (806) at least both (i) all reference objects 502 of each live object X, and (ii) all secondary objects 218 of each live object X as live (222) during garbage collection marking 308; and avoiding (812) embedding any reference sized space for holding references 224 to the secondary objects 218 within objects 220 that are not primary objects for holding references 224 to the secondary objects 218. Additional garbage collection operations, such as compaction 306 or sweeping 404, may also be performed (814).

[0057]

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

[0058]

[0070] As a further example, the following pseudocode shows the use of go_through_objects: if (ObjA.ContainsPointers||ObjA.IsPrimary) { go_through_objects(Objects ObjA, fn mark) { while (notend( )) { Object r = GetNextReference( ); mark(r); { } }

[0059]

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

[0060]

[0072] Some embodiments provide better performance by marking objects more quickly than traditional approaches (942). For example, some embodiments avoid reliance on looping through a handle table containing non-primary objects to collect secondary object handles (916). Some avoid relying on liveness promotion counters 922 to collect secondary object handles (920).

[0061]

[0073] Some embodiments set (924) a bit 702 embedded in the object to indicate that the object is a primary object before returning (926) a handle to the object as a result of the request to create the object.

[0062]

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

[0063]

[0075] Some embodiments in some situations treat the secondary as a primary and mark it accordingly. In some methods, treating a secondary object X as a primary object in its own right (930) includes marking (308) each reference object of object X and marking each secondary object of object X.

[0064]

[0076] Preconfigured Storage Media

[0077] Some embodiments include a configured computer-readable storage medium 112. The storage medium 112 may include disks (magnetic, optical, or other), RAM, EEPROM, or other ROM, and / or other configurable memory including, among other things, computer-readable storage media (not just propagating signals). The configured storage medium may be a removable storage medium 114 such as a CD, DVD, or flash memory, among other things. To form the configured storage medium, a general-purpose memory, which may be removable or non-removable and may be volatile or non-volatile, may be configured into an embodiment using items such as the IS-PRIMARY bit 702 or other space devoted to indicating primary 704, the primary object 216, the secondary object 218, the dependency handle 606, the primary-secondary relationship data structure 602, and the duplicated code path 246 that consolidates the marking of the reference object with the marking of the secondary object during garbage collection (938), in the form of data 118 and instructions 116 read from the removable storage medium 114 and / or another source such as a network connection. As disclosed herein, the configured storage medium 112 can cause the computer system 102 to perform technological process steps for memory management involving secondary objects. Thus, the figures help illustrate configured storage medium embodiments, and process (also referred to as method) embodiments, and system and process embodiments. In particular, any of the process steps shown in Figure 8 or Figure 9 or taught herein can be used to help configure a storage medium to form a configured storage medium embodiment.

[0065]

[0078] 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 method for memory management using secondary objects. The method includes indicating (802) whether each of a plurality of objects is a primary object 216 in a dedicated primary space 704 embedded within the plurality of objects, where each dedicated space 704 is smaller than an object reference 224, where the primary object is an object that has at least one secondary object 218, and where the secondary object is considered live by garbage collection if the primary object is live even if it is not a reference object of the primary object; treating the secondary objects as reference objects by marking (902) at least both (i) all reference objects 502 of each live object X, and (ii) all secondary objects 218 of each live object X as live during garbage collection marking (902); and avoiding (812) embedding any reference sized space for holding references to the secondary objects within objects that are not primary objects, where the size of each reference sized space is at least 32 bits.

[0066]

[0079] In some embodiments, merging the markings of secondary objects with the markings of reference objects contributes to the code exploitation and execution speed benefits of embodiments. In part, this merging involves code path duplication 242. Code paths overlap to the extent that they follow the same execution path.

[0067]

[0080] The overlap 242 can be measured in various ways. For example, overlap can be measured at the level of the stack. Assume that each letter represents an individual method or other routine that is invoked along the execution path. Then the path ABCDEFGKLM and the path ZYABCDEFGR have an overlap of ABCDEFG. If ABCDEFGKLM is the marking path of the reference object and ZYABCDEFGR is the marking path of the secondary object, then the overlap of ABCDEFG is 70% of the marking path of the reference object. Alternatively, the overlap 242 can be measured in terms of shared code blocks, or shared lines of code, or shared instructions. Unless otherwise specified, any of these measures 244 can be used and the percentage of overlap is whichever percentage is the largest. More broadly, when the enhanced GC marks (308), there is a common code path that does the work of "getting a reference and marking it." Because the marking of dependency handles is integrated into this common code, callers above the level of the marking of individual objects do not need to be aware of the distinction between the marking of reference objects and the marking of secondary objects, and no special handling is required when implementing function 202 in a system 102 that has not previously been hardened.

[0068]

[0081] Specifically, in some embodiments, the method includes following a reference object marking code path 246-RO for marking reference objects during garbage collection (904) and following a secondary object marking code path 246-SO for marking secondary objects during garbage collection (904). In some of these, at least 50 percent of the reference object marking code path overlaps with the secondary object marking code path (242). The overlap 242 is measured under at least one of the following overlap metrics 244: lines of code, instructions generated by the compiler, routines called, or stack frames, with or without library code, or both, and along all paths executed or all possible paths or just the shortest paths.

[0069]

[0082] In some embodiments, unified reference and secondary marking can provide increased flexibility because the marking of dependency handles can occur earlier, rather than being the last sub-phase of marking 308. Without such flexibility, the marking of dependency handles may have to be the last sub-phase in order to get complete results from all sub-phases that may make an object live, and therefore to be able to mark the secondaries of all primaries that are live. However, this inflexibility is inconsistent with making other sub-phases the last sub-phase of marking 308, potentially leading to multiple instances of the "last" sub-phase cleaning up after each other.

[0070]

[0083] In some embodiments, an enhanced marking method for marking of secondary objects that is integrated with marking of reference objects avoids imposing (932) a stop-the-world condition 406 (934) by marking secondary objects for garbage collection concurrently (810) with execution of an application program. Indeed, in some embodiments, the method is implemented as part of a background garbage collector. Thus, the method is performed (940) as part of a concurrent garbage collection. In other embodiments, the method is performed as part of a non-concurrent garbage collection. In either situation, the method can enhance performance by shortening the length of one or more STW sub-phases.

[0071]

[0084] In some embodiments, implementations avoid relying on looping (916) through any handle data structure that contains handles of both primary objects 216 and non-primary objects 220 to collect secondary object 218 handles for marking 308, thereby improving execution speed compared to some conventional approaches.

[0072]

[0085] Further details, examples, and discussion

[0086] Further support for the above discussion is provided below. For convenience, the subject matter of this further support appears under various headings. Nonetheless, it is intended that all of this further support be understood as an integral and integral part of the discussion of the present disclosure with respect to the contemplated embodiments.

[0073]

[0087] Concurrent Dependency Handle and Finalization Scans

[0088] Background Garbage Collection (BGC), a concurrent variant of GC, is optimized for latency in part by shortening parts of STW. One flow of non-enhanced BGC includes an Init initialization phase (done in STW), followed by a concurrent marking phase (non-STW), followed by a Final Mark final marking phase (STW), followed by a sweep phase. The final marking phase in this BGC includes catch-up, marking of dependency handles, short weak NULLING, finalization scan, and long weak NULLING sub-phases.

[0074]

[0089] In this BGC example, most of the marking work is done concurrently with the user threads, and the sweeping is all done concurrently. Init and Final Mark are done in STW and are usually very short. Init determines that a BGC cycle should be done and walks the call stack to populate the stack roots (no marking is done at this point). Final Mark starts by getting an accurate current state of the memory management state by doing a catch-up. Catch-up involves getting the current roots and re-marking them, this part of marking is typically quick since most of the objects have already been marked. Catch-up also involves revisiting parts of the heap that have been modified. Since most of the objects have already been marked there is often not much to do here (this example revisits concurrently during Concurrent Mark, so revisiting during STW is usually very fast as well).

[0075]

[0090] At this point the BGC knows which objects should be kept live, except for those in one of the following categories of constructs:

[0076]

[0091] Finalizable objects: The BGC goes through finalizable objects and promotes those that the GC finds dead and those that it will not let go of. This is called a finalization scan. Finalization can be used to help manage the lifetime of managed objects, for example by returning objects to the pool when the GC indicates that they are dead (their finalizers are run). The time it takes to promote a finalizable object that is found dead (to run its finalizer) and its children can be significant.

[0077]

[0092] Dependency Handles: BGC should look at the primary targets of dependency handles (DH) and promote their secondary objects with respect to live primary objects (treating them as live). If any secondary makes any DH's primary live, BGC should do the same for that DH. This is called a DH scan. DH was once rarely seen as it was only used in the Core Language Runtime for Edit and Continue. Later, some runtime use of DH was added, e.g. using dependency handles to interact with xaml. Core Language Runtime then exposed the ConditionalWeakTable. At that point, use of DH by some code was not uncommon, so the time it takes to promote an object with DH can be long when using non-hardened code.

[0078]

[0093] NULLing: NULLing a short or long weak handle target if the target is deemed dead. Note that in this example, the DH uses long and weak semantics so that the DH is NULLed along with the long and weak handle (e.g., in one implementation both are done within GCScan::GcWeakPtrScan). NULLing short / long weak handle targets may take a while if there are many handles, but the NULLing itself is quick, so taking such a long time is not expected to be a substantial performance issue.

[0079]

[0094] These categories of constructs are generally optional within an application 124; however, if present, this BGC example processes them during the Final Mark phase, which occurs in STW. If your code uses any or all of these categories of constructs, the likelihood of Final Mark times increasing as heap sizes grow. The teachings herein can be applied to reduce latency by concurrency of more garbage collections, for example by reducing or eliminating STW sub-phases.

[0080]

[0095] Some legacy code does not publicly expose types of dependent handles to user code, and user code can only indirectly create dependent handles by using the BCL API. The BCL (Base Class Library) is the lowest managed code layer that builds directly on top of the runtime. This implementation of the BCL API can allocate or free dependent handles. To the runtime, the BCL is user code but not end-user code, because the BCL can interact with the runtime in ways that end-user code cannot, for example to create dependent handles. At some point dependent handles can be publicly exposed to end-user code. To the extent that such exposure increases the use of dependent handles, the functionality 202 taught herein can provide a performance advantage (942).

[0081]

[0096] When considering how to enhance the traditional BGC with improved functionality 202, one goal is scalability. In some scenarios, there may be any number of objects or any number of dependency handles ready to be finalized. If these can run simultaneously or nearly simultaneously with application code, improved performance may be more desirable.

[0082]

[0097] In some scenarios, another consideration is how to preserve current program semantics. Some environments contain patterns where user code uses both short and weak handles to point to the same object, and the code assumes that if the target of the short and weak handle is null and the target of the long and weak handle is not null, the finalizer will run. Some embodiments preserve this behavior when doing things more concurrently. In some, the long and weak semantics of DH are preserved.

[0083]

[0098] In some scenarios, another consideration is how to make DH scan faster. In some legacy code, DH was considered as an add-on, so DH scan is done as a separate step. Non-hardened DH scan uses a naive algorithm that is not very performant. Non-hardened DH scan also does not integrate nicely with the rest of the BGC, in that it tries to be the last step during marking. This is bad because DH scan itself can cause other work, such as mark overflow, which could potentially lead to interleaving mark overflow and scanning DH. If there are other kinds of routes as well, they may try to interleave as well, making the code flow and design even more cumbersome.

[0084]

[0099] The teachings herein address both shortcomings of non-enhanced DH scan. The teachings herein describe enhanced ways of handling DH scan and making it more concurrent. With the following considerations in mind, one skilled in the art can know how to incorporate enhanced DH scan into existing marking codes.

[0085]

[0100] First, a DH or other primary-secondary relationship dictates that if the primary object is considered live, then its secondary objects should be considered live. This lifetime consideration is the same as for any references the primary object contains: if an object is marked (considered live), then all references it contains should be marked. If the object is the primary object of a DH or multiple DHs, then its corresponding secondary objects should also be marked.

[0086]

[0101] Second, when the GC marks an object, it takes the references the object contains and marks them. In some legacy code, it does this in a routine called go_through_objects that decodes information that tells the GC where to find the references that the object contains. If the hardening code sees that the object has corresponding secondaries, it can also merge them as references for marking purposes, so that go_through_objects or similar object relationship tracing routines in other implementations will also mark them. Secondaries do not become reference objects for purposes other than marking, so for example a debugger cannot trace from a primary to a secondary by simply following the addresses embedded in the primary.

[0087]

[0102] Some embodiments include an IRM function 202, where IRM is an acronym for Integrated Reference Marking. The IRM function 202 integrates the marking of reference objects with the marking of secondary objects, so it can also be called "integrated reference and secondary marking." The IRM function 202 allows the marking 308 to know about the integrated references added by DH. The IRM automatically includes all references (to conventional or secondary objects) that each object contains, so code paths that call go_through_objects etc. can remain unchanged when the IRM function 202 is added. This is a much more elegant solution than the previous separate DH scans, and by leveraging the existing simultaneous marking of reference object scans, it becomes easier to do simultaneous DH scans.

[0088]

[0103] One aspect of the IRM functionality 202 is a smart way to know which secondaries correspond to a primary object. The hardening code should know when to check an object for secondaries. This is accomplished by using and checking the IS-PRIMARY bit. A bit is set to indicate that there are one or more secondaries, and a given primary object can have multiple secondaries. In one implementation, the IS-PRIMARY bit is embedded in the syncblock on 64-bit systems. This does not preclude implementations with 32-bit address spaces, but the relative performance gains can be significantly higher for 64-bit systems since they can have much larger heaps than 32-bit systems.

[0089]

[0104] Hardened code with IRM functionality 202 should also be able to get the secondaries of objects that have the IS-PRIMARY bit set. Some embodiments include a hash table 602 of objects that are primaries for DH. To avoid problems due to unstable hashes, some embodiments use the hash code for the primary object as the hash table key. This table 602 should be built by the DH operations, e.g., when a primary is set for DH, it should be inserted into the primary hash table with its secondaries as its value (or as one of the values ​​if there are multiple secondaries for that primary). When the primary for a DH is changed, the old primary is removed from the hash table and the new one is inserted. To avoid very fine-grained synchronization when the BGC is also looking at this hash table, some embodiments can have the BGC lock (STW), work for a while, and then release the lock.

[0090]

[0105] In this way, DH scans can be intermixed with normal marking. However, one further consideration in some scenarios is how to record DH modifications to be tracked by revisit code. In legacy code, heap modifications may be tracked by write barriers that record the modifications in a write monitor table. To achieve a similar effect for DH marking, some embodiments record modifications of DH primary so that the marking code revisits those modified secondaries. In the handle table, the code may already invoke a handle table write barrier (e.g., HndWriteBarrier or similar barriers in other environments) to adjust the age. Hardened code can also take this opportunity to record primary objects in the write monitor table using write barrier code.

[0091]

[0106] As an aside, some embodiments omit a separate DH scan in Final Mark. If there is any modification to a secondary of a primary, that modification is reflected by the handle table write barrier so that the primary is naturally revisited. If a new primary is added (either by modifying the DH primary or allocating a new DH), that secondary will be constructed before garbage collection aborts the execution engine. During STW, the garbage collector has access to the relationship of secondaries to primaries, so that when a primary object is marked, the garbage collector can figure out which secondaries should also be marked.

[0092]

[0107] One flow of the enhanced BGC includes an Init initialization phase (STW), followed by a concurrent marking phase (non-STW) with integrated marking, followed by a Final Mark final marking phase (STW) with integrated marking that also does catch-up and short weak NULLING, followed by a concurrent finalize scan phase (non-STW) with integrated marking, followed by long weak NULLING (STW), followed by a sweep phase. This enhanced BGC workflow tends to have shorter STW time than the non-enhanced BGC workflow described above, thereby improving application performance.

[0093]

[0108] Technical characteristics

[0109] The technical properties of the embodiments described herein will be apparent to those skilled in the art and in some respects to the broad and attentive reader. Some embodiments address technical activities such as setting or clearing bits, following pointers, allocating memory, creating or updating hash tables, and managing memory in computer systems, each of which are activities 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, reduced storage requirements for non-primary objects, merging the marking of reference objects with the marking of secondary objects during garbage collection, increased concurrency, reduced STW time, and avoidance of certain inefficiencies during garbage collection. Thus, purely intellectual processes are expressly excluded. Other advantages based on the technical properties of the present teachings will also be apparent to those skilled in the art from the description provided.

[0094]

[0110] Some may take some of the embodiments described herein 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, the broad context does not imply that an exclusive right to abstract ideas is sought herein, and there is no such thing. Rather, this disclosure focuses on providing appropriately specific embodiments whose technical effect fully or partially solves a particular technical problem, such as how to increase the synchronicity of garbage collection with application software. Other configured storage media, systems, and processes that include usage, size, collection, management, or relationships are outside the scope of the present invention. Thus, by properly understanding this disclosure, ambiguity, mere abstraction, lack of technical characteristics, and attendant proof problems are also avoided.

[0095]

[0111] Further Combinations and Modifications

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

[0096]

[0113] More generally, those skilled in the art will appreciate that not all parts of the present disclosure or any specific details therein are necessarily required to satisfy legal standards such as enablement, written description, or best mode. Furthermore, embodiments are not limited to the selection of specific motivating examples, programming languages ​​or libraries or runtimes, software processes, development tools, identifiers, data structures, data organization, annotations, control flows, pseudocode, naming conventions, or other implementations described herein. Any apparent inconsistency with any other patent disclosure, even that of the owner of the present innovation, is not helpful in interpreting the scope of the claims presented in this patent disclosure.

[0097]

[0114] Acronyms, Abbreviations, Names, and Symbols

[0115] Certain acronyms, abbreviations, names, and symbols are defined below. Others are defined elsewhere in this specification or do not need to be defined here to be understood by those of ordinary skill in the art.

[0098]

[0116] ALU: Arithmetic Logic Unit

[0099]

[0117] API: Application Program Interface

[0100]

[0118] BIOS: Basic Input / Output System

[0101]

[0119] CD:Compact Disc

[0102]

[0120] CPU: Central Processing Unit

[0103]

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

[0104]

[0122] FPGA: Field Programmable Gate Array

[0105]

[0123] FPU: Floating Point Processing Unit

[0106]

[0124] GPU: Graphical Processing Unit

[0107]

[0125] GUI: Graphical User Interface

[0108]

[0126] IaaS or IAAS: Infrastructure as a Service

[0109]

[0127] IoT: Internet of Things

[0110]

[0128] LAN: Local Area Network

[0111]

[0129] OS: Operating System

[0112]

[0130] PaaS or PAAS: Platform as a Service

[0113]

[0131] RAM: Random Access Memory

[0114]

[0132] ROM: Read-Only Memory

[0115]

[0133] TPU: Tensor Processing Unit

[0116]

[0134] UEFI: Unified Extensible Firmware Interface

[0117]

[0135] WAN: Wide Area Network

[0118]

[0136] Some further terms

[0137] Although reference is made herein to exemplary embodiments as illustrated in the figures and specific language is used herein to describe such embodiments, alterations and further modifications of the features illustrated herein, and further technical applications of the abstract principles illustrated by the specific embodiments herein, which would occur to one of ordinary skill in the relevant art and possessing ownership of this disclosure, should be considered within the scope of the appended claims.

[0119]

[0138] The meaning of terms is clarified in this disclosure, and therefore the claims should be read with attention to these clarifications. Specific examples are given, but one skilled in the art will understand that other examples may be included in the meaning of the terms used and within the scope of one or more claims. Terms herein do not necessarily have the same meaning as they have in common usage (especially non-technical usage), or in a particular industry usage, or in a particular dictionary or set of dictionaries. Reference numbers may be used with various wordings to help indicate the breadth of terms. The omission of a reference number from a given piece of text does not necessarily mean that the contents of the figure are not discussed by that text. The inventors claim and exercise their rights to specific and selected lexicography. Terms in quotation marks are expressly defined, but terms may also be implicitly defined without the use of quotation marks. Terms may be explicitly or implicitly defined here in the detailed description and / or elsewhere in the application file.

[0120]

[0139] As used herein, a "computer system" (also known as a "computing system") may include, for example, one or more servers, motherboards, processing nodes, laptops, tablets, personal computers (portable or not), personal digital assistants, smartphones, smart watches, smart bands, cell or mobile phones, other mobile devices having at least a processor and memory, video game consoles, augmented reality systems, holographic projection systems, televisions, wearable computing systems, and / or other devices that provide one or more processors that are at least partially controlled by instructions. The instructions may take the form of firmware or other software in memory and / or specialized circuitry.

[0121]

[0140] A "multi-threaded" computer system is one that supports multiple threads of execution. The term "thread" should be understood to include code that can be or is subject to scheduling and possibly synchronization. Threads may be known by other names outside this disclosure, e.g., "tasks," "processes," or "coroutines." However, we distinguish between threads and processes herein in that threads define paths of execution within a process. Furthermore, the threads of a process share a given address space, whereas different processes have different individual address spaces. The threads of a process may be executed in parallel, sequentially, or a combination of parallel and sequential execution (e.g., time slicing).

[0122]

[0141] A "processor" is a thread processing unit, such as a core in a simultaneous multithreading implementation. A processor includes hardware. A given chip may hold one or multiple processors. Processors can be general purpose or customized for a specific application, such as vector processing, graphics processing, signal processing, floating point arithmetic processing, cryptography, I / O processing, machine learning, etc.

[0123]

[0142] A "kernel" includes operating systems, hypervisors, virtual machines, BIOS or UEFI code, and similar hardware interface software.

[0124]

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

[0125]

[0144] "Program" is used broadly herein to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (also referred to as developers) and / or automatically generated.

[0126]

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

[0127]

[0146] With regard to "reference objects" versus "secondary objects", one skilled in the art will recognize that ordinary references to objects may be explicitly declared in source code, for example as pointer fields, and that dependent handles may also be explicitly declared in source code. However, in some embodiments, the identification of these somewhat related objects differs in their use and their storage requirements. An ordinary reference in an object A that references another object involves allocating a reference-sized field in A that necessarily never identifies some other object B. Even if A never references some other object B, the code always incurs the storage cost of that field in A. In contrast, a dependent handle establishes a relationship between object A and another object B (i.e., if A is alive, then B is considered alive). Only if there is an actual relationship between a particular object A and a particular object B will a dependent handle for object A use a reference-sized field to identify B.

[0128]

[0147] The terms "reference", "address", "pointer", and "handle" are used herein to discuss denial of an object that is at least the size of the reference in terms of storage, e.g., at least N bits in an N-bit virtual address space, or more simply, each one larger than the IS-PRIMARY bit.

[0129]

[0148] As used herein with respect to objects, "contain" is used more broadly than "embed." "Contain" covers containment by reference, dependent handle, or contiguous allocation, whereas "embed" requires contiguous allocation. Thus, if object A has a pointer to object B, A contains B and the pointer is embedded in A, but B itself is not embedded in A. This distinction bears in mind the difference between (a) supporting dependent objects by embedding a reference-size field in all objects when they are used as primary objects, and (b) supporting dependent objects by embedding only a single bit (the IS-PRIMARY bit) and using the reference-size field (in the hash table) only for objects that are actually primary objects.

[0130]

[0149] "Cloud" means pooled resources for computing, storage, and networking that are elastically available for measured, 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 another service. Unless otherwise specified, any reference to reading from or writing to a file includes doing a local file read / write, or a read / write over a network, which may be a cloud network or another network, or both (local and networked read / write).

[0131]

[0150] "IoT" or "Internet of Things" means any networked collection of addressable embedded computing nodes. Such nodes are examples of computer systems as defined herein, but further 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 sensors that track sources of non-verbal data, (d) no local rotating disk storage (RAM or ROM chips provide the only local memory), (e) no CD or DVD drive, (f) embedded in a home appliance or home accessory, (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, urban infrastructure monitoring, industrial equipment monitoring, energy usage monitoring, human or animal health monitoring, physical security, or physical transportation system monitoring. IoT storage can be targeted for unauthorized access by the cloud, by another network, or by direct local access attempts.

[0132]

[0151] "Access" to a computational resource includes using a permission or other capability to read, modify, write, execute, or otherwise utilize the resource. Although attempted access may be clearly distinguished from actual access, "access" without the "attempted" qualifier includes both attempted access and actual access that has been made or provided.

[0133]

[0152] As used herein, unless otherwise specified, "include" allows for additional elements (i.e., includes means comprises).

[0134]

[0153] "Optimization" means to improve, but not necessarily completely. For example, it may be possible to further improve a program or algorithm that has been optimized.

[0135]

[0154] "Process" is sometimes used herein as a term in the computing field, and in its technical sense encompasses a computing resource user that may also include or be referred to as, for example, a co-routine, a thread, a task, an interrupt handler, an application process, a kernel process, a procedure, or an object method. In practice, a "process" is a computing entity identified by a system utility such as Windows Task Manager, Linux ps (trademarks of Microsoft Corporation and Linus Torvalds, respectively), or similar utilities in other operating system environments. "Process" is also used herein as a patent law term, for example, when writing process claims as opposed to system claims or product (configured storage medium) claims. Similarly, "method" is sometimes used as a technical term in the computing field (a type of "routine") and as a patent law term ("process"). "Process" and "method" in the patent law sense are used interchangeably herein. Those skilled in the art will understand which meaning is intended in a particular example, and will also understand that a given process or method (in the patent law sense) recited in the claims may be implemented using one or more processes or methods (in the electronic computing sense).

[0136]

[0155] "Automatically" means using automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein) as opposed to no automation. Specifically, steps performed "automatically" are not performed by hand on paper or in a person's mind, but may be initiated by a human or interactively guided by a human. Automatic steps are performed by a machine to achieve one or more technical effects that would not be realized without such provided technical interaction. Automatically performed steps are presumed to include at least one operation that is performed proactively.

[0137]

[0156] Those skilled in the art will understand that technical effects are for the purpose of estimating technical embodiments. For example, the mere fact that an embodiment involves calculations and that some calculations can also be performed without technical components (e.g., by paper and pencil, or even by mental steps) does not eliminate the existence of the technical effects or change the concrete and technical nature of the embodiment. It will be understood that memory management operations such as marking an object, identifying a reference object, identifying a secondary object, and many other operations discussed herein are digital in nature. The human mind cannot directly interact with a CPU or other processor, or with a RAM or other digital storage, to read and write the necessary data and perform the memory management steps taught herein. All of this will be well understood by those skilled in the art in light of the present disclosure.

[0138]

[0157] "Computationally" also means that a computing device (at least a processor and memory) is used, and excludes obtaining a result solely by mere human thought or mere human activity. As understood herein, performing arithmetic using, for example, paper and pencil is not performing arithmetic computationally. A computational result is faster, more extensive, deeper, more accurate, consistent, comprehensive, and / or otherwise provides a technical effect that is beyond the scope of human performance alone. A "computational step" is a step that is performed computationally. Neither "automatically" nor "computationally" necessarily means "instantaneously." "Computationally" and "automatically" are used interchangeably herein.

[0139]

[0158] "Proactively" means without direct request from a user. In fact, a user may not even realize that a proactive step according to an embodiment was possible until the results of the step are presented to the user. Unless otherwise specified, any computational and / or automated steps described herein may also be performed proactively.

[0140]

[0159] Throughout this specification, the optional plural forms "(s)", "(es)", or "(ies)" mean that one or more of the indicated feature are present. For example, "processor(s)" means "one or more processors" or, equivalently, "at least one processor."

[0141]

[0160] Under U.S. law and practice, the use of the word "step" in this specification, in the claims, or elsewhere 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 hereby expressly rebutted.

[0142]

[0161] Under U.S. law and practice, claims are not intended to invoke a means-plus-function interpretation unless the phrase "means for" is used. If any claim language is intended to be interpreted as means-plus-function language, that intent is clearly explained by using the phrase "means for." When a means-plus-function interpretation is applicable by using "means for" and / or by a court's legal interpretation of the claim language, the means recited herein for a given noun or a given verb should be understood to be linked to the claim language and to be linked to each other herein by appearing in the same block in a block diagram of the drawings, by being labeled with the same or similar name, by being labeled with the same reference number, by a functional relationship shown in any of the drawings, or by a functional relationship described in the text of this disclosure. For example, if a claim limitation recites "zac widget" and that claim limitation is subject to means-plus-function interpretation, then at a minimum, all structures identified anywhere in this specification in any drawing block, paragraph, or example that refers to "zac widget," or that are linked to one another by any reference number assigned to the zac widget, or that are disclosed as having a functional relationship to the structure or operation of the zac widget, are considered to be part of the structure identified in the application related to the zac widget and help define a set of equivalents for the structure of the zac widget.

[0143]

[0162] Those skilled in the art will appreciate that this innovation disclosure discusses various data values ​​and data structures, and will understand that such items reside in memory (RAM, disk, etc.), thereby constituting memory. Those skilled in the art will also appreciate that this innovation disclosure discusses various algorithmic steps that are embedded in executable code in a given implementation, and that such code is also in memory, and that such code effectively constitutes any general-purpose processor that executes such code, thereby functionally transforming the processor from a general-purpose processor into a special-purpose processor that is dedicated hardware.

[0144]

[0163] Thus, one of ordinary skill in the art would not make the mistake of treating (a) a memory recited in a claim and (b) a data structure or data value or code recited in a claim as non-duplicate items. Even if a claim does not explicitly recite every data structure or data value or piece of code referred to, it will be understood that the data structures and data values ​​and code are so recited in the memory. Thus, an explicit recitation of such is not required. However, such a recitation is not prohibited, and one or two alternative recitations may be present for emphasis without excluding the presence of all other data values ​​and data structures and code. Similarly, the function of code recited in a claim will be understood to constitute a processor, whether or not that constituent quality is explicitly recited in the claim.

[0145]

[0164] Throughout this specification, unless otherwise specified, any reference to a step in a process presumes that the step may be performed directly by an interested person and / or indirectly by a party through an intervening mechanism and / or entity and still be included within the scope of the step, i.e., direct performance of a step by an interested person is not required unless direct performance is an expressly stated requirement. Steps involving actions by an interested party, such as, for example, allocating, verifying, clearing, embedding, enumerating, executing, following, directing, looping, managing, marking, measuring, doing, providing, setting, designating, replacing, handling, updating, or using with respect to an object or other subject (as well as allocating, assigned, verifying, verified, etc.), may involve intervening actions as above or of transferring, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, invoking, etc., by some other party, including any of the actions enumerated herein, but still understood to be performed directly by the interested party.

[0146]

[0165] Whenever data or instructions are mentioned, it will be understood that those items constitute computer-readable memory and / or computer-readable storage medium, thereby turning the memory or medium into a specific item, as opposed to, for example, simply existing on paper, in one's head, or as mere signals propagating over wires. For purposes of patent protection in the United States, memory or other computer-readable storage medium is not a propagating signal or carrier wave or mere energy outside the scope of patentable subject matter under the interpretation of the United States Patent and Trademark Office (USPTO) in In re Nuijten. No claim in the United States covers signals per se or mere energy, and any claim construction asserting otherwise in light of this disclosure is literally unjust. Unless expressly stated otherwise in a claim granted outside the United States, no claim covers signals per se or mere energy.

[0147]

[0166] Moreover, notwithstanding anything to the contrary elsewhere in this specification, 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 referred to as signal media, on the other hand. Transmission media are computer-readable media of a propagating signal or carrier wave. In contrast, computer-readable storage media and computer-readable memory are not computer-readable media of a propagating signal or carrier wave. Except as expressly stated otherwise in the claims, "computer-readable medium" refers to computer-readable storage media and not to a propagating signal per se, and not to mere energy.

[0148]

[0167] The "embodiments" herein are examples. The term "embodiments" is not synonymous with "the invention." Even if the resulting combination of aspects is not explicitly described herein in itself, embodiments may freely share or borrow aspects (provided the result is operable) to create other embodiments. Requiring every permitted combination to be explicitly and individually described is unnecessary for a person skilled in the art and runs counter to the policy of recognizing that patent specifications are written for a reader who is skilled in the art. Formal combinatorial calculations and informal general intuition regarding the number of possible combinations resulting from even a small number of features that can be combined also indicate that there are a large number of combinations of aspects for the aspects described herein. Thus, requiring every combination to be explicitly listed runs counter to the policy of requiring patent specifications to be concise and the reader to be familiar with the relevant technical field.

[0149]

[0168] List of reference numbers

[0169] The following list is provided for convenience and to aid in drawing, and as part of the text of this specification to represent innovations by reference to multiple items. Items not listed here may still be part of a given embodiment. To make the text more readable, a given reference number is written near some, but not all, descriptions of the referenced items in the text. The same reference number may be used for different examples or different instances of a given item. The list of reference numbers is as follows:

[0150]

[0170] 100 Operating environment, also called computing environment

[0151]

[0171] 102 Computer system, also called computational system or computing system

[0152]

[0172] 104 Users, e.g. software developers

[0153]

[0173] 106 Peripheral Devices

[0154]

[0174] 108 Networks in general, including LANs, WANs, software-defined networks, clouds, and other wired or wireless networks

[0155]

[0175] 110 Processor

[0156]

[0176] 112 Computer-readable storage medium, e.g., RAM, hard disk

[0157]

[0177] 114 Removable configured computer readable storage medium

[0158]

[0178] 116 Processor executable instructions, which may be on a removable storage medium or in other memory (volatile or non-volatile or both)

[0159]

[0179] 118 Data

[0160]

[0180] 120 Kernels, e.g. operating systems, BIOS, UEFI, device drivers

[0161]

[0181] 122 Tools, such as anti-virus software, firewalls, packet sniffer software, intrusion detection systems, intrusion prevention systems, other cybersecurity 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 tool suites (including, for example, integrated development environments), hardware development tools and tool suites, diagnostics, etc.

[0162]

[0182] 124 Applications, such as word processors, web browsers, spreadsheets, games, email tools, commands

[0163]

[0183] 126 Display screen, also called "display"

[0164]

[0184] 128 Computing hardware not otherwise related to reference numbers 106, 108, 110, 112, 114

[0165]

[0185] 200 A system enhanced with a garbage collection memory management function including some or all of function 202

[0166]

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

[0167]

[0187] 204 Garbage Collector, also called "GC" or "Garbage Collector Code"

[0168]

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

[0169]

[0189] 208 Mutator thread, i.e. a thread that is at least primarily (more than 50% of instructions) devoted to code other than the garbage collector code. Mutator threads are often user threads but can be kernel threads. The "mutator" in the term indicates that a mutator thread can mutate (i.e. change) the addresses used during garbage collection.

[0170]

[0190] 210 Garbage Collector Marking Phase Codes

[0171]

[0191] 212 Objects, e.g. object data structures allocated within a program that implements the object-oriented programming paradigm. They may be implemented using, e.g., classes, structures, unions, members, fields, constructors, and destructors.

[0172]

[0192] 214 The heap portion of memory, often simply called the "heap"

[0173]

[0193] 216 Primary object, i.e. an object that has at least one secondary object

[0174]

[0194] 218 secondary object, an object that should be marked as live if its primary object is live. A secondary object may be identified by a mechanism other than embedding its address in a reference field in its primary object, for example a secondary object may be identified in a hash table of primary-secondary relationships.

[0175]

[0195] 220 Non-primary objects, i.e. objects that do not have secondary objects and may or may not have any reference objects

[0176]

[0196] 222 Live objects, i.e. objects that are marked as live (still in use) by the garbage collector

[0177]

[0197] 224 object reference, a value embedded within an object that identifies another object. A reference can also be called a "pointer" or "object address" or "link" or "handle". 224 also refers to the reference field, which typically has at least as many bits as the address contains the referenced object in any address space, 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 somewhat smaller (e.g. 16 bits or 24 bits or 48 bits).

[0178]

[0198] 226 Floating garbage, i.e. memory that is unused but not yet marked for reuse

[0179]

[0199] 228 Handle Table

[0180]

[0200] 230 reachable memory, i.e. memory that is reachable by heap roots or other data structures that connect allocated memory pieces

[0181]

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

[0182]

[0202] 234 Marked Memory

[0183]

[0203] 236 Unmarked Memory

[0184]

[0204] 238 memory in use

[0185]

[0205] 240 unused memory

[0186]

[0206] 242 overlap of code paths during execution, which can be measured using one or more overlap metrics 244. Number 242 also refers to the action of overlapping two or more code paths, for example, by designing and constructing a program that creates overlaps in execution.

[0187]

[0207] 244 Code duplication metrics, e.g., the degree to which two (or more) code paths overlap in terms of their individual lines of code, number of instructions generated by the compiler, number of routines called, or number of stack frames

[0188]

[0208] 246 The path the code takes during execution; specifically, 246-RO indicates the reference object marking code path, and 246-SO indicates the secondary object marking code path.

[0189]

[0209] 300 A segment of memory, e.g., an area, page, block, or other region of memory that is at least partially managed by garbage collection.

[0190]

[0210] 302 Allocated, not sure if in use or available for reuse (see Figure 3)

number

[0191]

[0211] 304 Reusable contiguous memory areas resulting from compaction

[0192]

[0212] 306 Compaction, e.g., rearranging one or more reusable regions to create a larger contiguous region that can be reused.

[0193]

[0213] 308 Marking. Action taken during garbage collection to mark memory areas as (i) not known to be in use or available for reuse, or (ii) known to be available for reuse.

[0194]

[0214] 400 Threads in General

[0195]

[0215] 402 Garbage Collection Phases and Sub-Phases

[0196]

[0216] 404 Garbage collection sweep phase

[0197]

[0217] 406 Stop-the-World Subphase of Garbage Collection, also known as "STW"

[0198]

[0218] 502 Reference Object

[0199]

[0219] 504 A variable declared or used to hold a pointer to an object

[0200]

[0220] 506 Format information embedded within the storage space allocated to an object

[0201]

[0221] 602 A hash table or other data structure that represents the primary-secondary relationship. 602 also refers to the primary-secondary relationship.

[0202]

[0222] 604 Entries in the data structure 602

[0203]

[0223] 606 Dependency handle, a handle that identifies a primary-secondary relationship between objects. A dependency handle has a primary object and a secondary object associated with it, and relating two objects in this way using a dependency handle forms a garbage collection relationship between the objects. If the primary object is alive, the secondary object is also considered alive.

[0204]

[0224] 700 bits (i.e. memory locations whose capacity is one binary digit)

[0205]

[0225] 702 IS-PRIMARY bit, i.e. a bit whose value indicates whether the object in which it is embedded is a primary object or not

[0206]

[0226] 704 Space within the object dedicated to memory management of secondary objects. Space 704 may include one or more bits, and may (depending on the implementation) include or consist of the IS-PRIMARY bit 702, among others, and may include other bits, for example to indicate the minimum generation of the reference to be added.

[0207]

[0227] 800 Flowchart. 800 also refers to a memory management method illustrated by or consistent with the flow chart of FIG.

[0208]

[0228] 802 Indicate whether an object is a primary object, for example by setting or clearing IS-PRIMARY 702.

[0209]

[0229] 804 Primaryness, e.g. whether the object is a primary object

[0210]

[0230] 806 Set object liveness

[0211]

[0231] 808 uses integrated reference and secondary markings. 808 also refers to the integration of these types of markings.

[0212]

[0232] 810 running at the same time

[0213]

[0233] 812 Avoid embedding reference size space in every object if it just happens to be a primary object

[0214]

[0234] 814 General garbage collection processing

[0215]

[0235] 816 Embedding bit variables or other data structures within an object

[0216]

[0236] 900 Flowchart. 900 also refers to a memory management method illustrated by or consistent with the flow chart of FIG. 9 (which incorporates the steps of FIG. 8).

[0217]

[0237] 902 Treat secondary objects as reference objects for marking 308

[0218]

[0238] Follow the 904 code path

[0219]

[0239] 906 Check object for viability

[0220]

[0240] 908 Enumerate object references, addresses or handles

[0221]

[0241] 910 Receive command

[0222]

[0242] 912 Replacing one object with another

[0223]

[0243] 914 Update Data Structure

[0224]

[0244] 916 Avoid relying on looping through the complete table when enumerating objects for marking (908), i.e. looping through a table that contains both primary and non-primary objects.

[0225]

[0245] 918 Loop through the complete table (including both primary and non-primary objects)

[0226]

[0246] 920 Avoid relying on promotion counters when enumerating objects for marking (908)

[0227]

[0247] 922 Promotion counters, e.g., a counter of how many secondary objects are still marked as alive, or how many secondary objects are still being visited during marking

[0228]

[0248] 924 Set the IS-PRIMARY bit to indicate that the object is a primary object

[0229]

[0249] 926 For example, returning an object handle as the return value of an object constructor

[0230]

[0250] 928 Specifying secondary objects within the data structure 602, e.g., representing a primary-secondary relationship

[0231]

[0251] 930 Treating secondary objects as primary objects in their own right

[0232]

[0252] 932 Avoiding the imposition of stop-the-world conditions

[0233]

[0253] 934 Impose a stop-the-world condition

[0234]

[0254] 936 Managing memory in a computing system

[0235]

[0255] 938 Garbage collection as part of memory management

[0236]

[0256] 940 As part of a concurrent garbage collection

[0237]

[0257] 942 Bring at least one efficiency

[0238]

[0258] 944 Efficiency, e.g. faster marking, lower storage requirements for objects, simpler code design

[0239]

[0259] 946 Any step discussed in this disclosure that is not assigned any other reference number

[0240]

[0260] conclusion

[0261] In brief, the teachings herein provide memory management features 202 for various computing systems 102 that enhance the performance of applications 124 that use managed memory 112. Efficiently managing (936) secondary objects 218 enhances garbage collection concurrency (810) and reduces storage requirements for objects 212. Liveness markings 308 of secondary objects 218 are merged (808) with liveness markings 308 of referencing objects 502. Allocating reference-sized secondary object identifier fields (224 in FIG. 5) in objects 220 that are not primary objects is avoided (812), and a dedicated bit 702 designates a primary object 216. A primary object 216 is an object 212 that has at least one secondary object 218, and a secondary object 218 is considered live by garbage collection (938) if the primary object 216 is live (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 a live primary object 216 are also considered to be still live (806). To allow for more efficient (944) marking 308 of secondary objects, the code path 246-RO for marking (308) reference objects 502 may be shared with the code path 246-SO for marking (308) secondary objects 218. The primary-secondary object relationships 602 may be represented by dependency handles 606, which may be specified (928) in a hash table 602 or other data structure.

[0241]

[0262] It will be appreciated that embodiments may themselves further include or benefit from tested and appropriate security and privacy controls, such as General Data Protection Regulation (GDPR), and should take appropriate steps to help prevent unauthorized use of the computing system, for example by injection or activation of malware within the software, and use of the tools and techniques taught herein may be compatible with the use of such controls.

[0242]

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

[0243]

[0264] Although certain embodiments are specifically illustrated and described herein as processes, configured storage media, or systems, it will be understood that the discussion of one type of embodiment generally extends to other types of embodiments. For example, the discussion of a process with respect to Figures 8 and 9 also helps to explain the configured storage media, and also helps to explain the technical effects and operation of systems and articles of manufacture as discussed with respect to other figures. The limitations of one embodiment are not necessarily carried over to another embodiment. In particular, a process is not necessarily limited to the data structures and configurations presented while discussing a system or article of manufacture such as a configured memory.

[0244]

[0265] Those skilled in the art will appreciate that implementation details may relate to specific thresholds, comparisons, sample fields, specific types of runtimes or programming languages ​​or architectures, specific code such as specific scripts or other tasks, and specific computing environments, and thus need not appear in all embodiments. Those skilled in the art will also appreciate that program identifiers and some other terminology used in discussing the details are implementation specific, and thus need not pertain to all embodiments. Nonetheless, while not required to be present in this specification, such details may assist some readers by providing context and / or illustrate some of the many possible implementations of the techniques discussed herein.

[0245]

[0266] By giving due attention to the items provided herein, including technical processes, technical effects, technical mechanisms, and technical details, which are illustrative rather than exhaustive of all embodiments as claimed or which may be described, those skilled in the art will understand that the present disclosure and the embodiments described herein are not directed to subject matter outside the technical field, or any idea thereof, such as the primary or original cause or motivation, or the mere result per se, or intellectual processes or steps, or business methods or prevailing economic practices, or mere methods of organizing human activity, or laws of nature per se, or naturally occurring events or processes, or living organisms or parts of living organisms, or mathematical formulas per se, or isolated software per se, or merely conventional computers, or any thing or any abstract idea per se that is completely inperceivable, or insignificant post-solution acts, or any method that is implemented entirely on unspecified equipment, or any method that does not produce a useful and tangible result, or any preemption of any field of use, or any other subject matter that is ineligible for patent protection under the laws of any jurisdiction where patent protection is sought or granted or enforced.

[0246]

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

[0247]

[0268] Not all items shown must be present in all embodiments. Conversely, an embodiment may include items not explicitly shown in the drawings. Although some possibilities are illustrated herein in the text and drawings by way of example, embodiments may deviate from those examples. For example, certain technical effects or technical features of an example may be omitted, relabeled, grouped differently, repeated, instantiated differently in hardware and / or software, or may be a mixture of effects or features appearing in two or more of the examples. Those skilled in the art will appreciate that in some embodiments, functionality shown in one location may be provided in a different location, and that functional modules may be defined in various ways in a given implementation without necessarily omitting a desired technical effect from the collection of interacting modules taken as a whole. Due to space limitations or for convenience, separate steps may be shown together in a single box in the figures, but may still be performed separately, e.g., some steps may be performed without other steps in a given execution of the method.

[0248]

[0269] Reference numbers have been used to refer to the drawings throughout. Any apparent discrepancy in the language associated with a given reference number in the drawings or text should be understood as merely broadening the scope of the content referenced by that number. Even if the same reference number is used, different instances of a given reference number may refer to different embodiments. Similarly, a given reference number may be used to refer to a verb, a noun, and / or a respective corresponding instance, e.g., processor 110 may process instructions (110) by executing the instructions.

[0249]

[0270] As used herein, terms such as "a," "an," and "the" include one or more of the indicated items or steps. Specifically, in the claims, a reference to an item broadly means that there is at least one of that item, and a reference to a step means that at least one instance of the step is performed. Similarly, to avoid grammatical errors or misunderstandings, "is" and other singular verb forms should be understood to include "are" and other plural possibilities when the context permits.

[0250]

[0271] Headings are for convenience only, and information on a given topic may be found outside the section whose heading identifies that topic.

[0251]

[0272] All claims and the abstract filed are incorporated herein by reference.

[0252]

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

[0253]

[0274] Although exemplary embodiments have been shown and described above, it will be apparent to those skilled in the art that numerous modifications can be made without departing from the principles and concepts set forth in the claims, and that such modifications need not encompass complete abstractions. Although the present subject matter has been described in language specific to structural features and / or procedural acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific technical features or acts set forth above, claims. It is not necessary that all means or aspects or technical effects identified in a given definition or example be present or utilized in all embodiments. Rather, the specific features and acts and effects described are disclosed as examples to be considered when implementing the claims.

[0254]

[0275] All changes that come within the meaning and range of equivalency of the claims, but not all abstract concepts, are intended to be embraced within the claims to the fullest extent permitted by law.

Claims

1. 1. A system configured for memory management using secondary objects, comprising: Memory, a processor in operative communication with the memory, the processor configured to perform steps for memory management including: (a) indicating whether each of a plurality of objects is a primary object in a private space embedded within the plurality of objects, each private space being smaller than an object reference, a primary object being an object having at least one secondary object, a secondary object being considered live by garbage collection if the primary object is live even if it is not a reference object of the primary object; and (b) treating secondary objects as reference objects during garbage collection marking by marking as live at least both (i) all reference objects of each live object X, and (ii) all secondary objects of each live object X. Including, whereby during garbage collection the marking of reference objects is merged with the marking of secondary objects to recover memory for further use without requiring non-primary objects to pad reference-sized space for holding references to secondary objects; system.

2. 2. The system of claim 1, further comprising a hash table having entries, the hash table entries including a primary object reference to the primary object and a secondary object reference to the secondary object, thereby indicating that the secondary object is a secondary object of the primary object.

3. 2. The system of claim 1, wherein each dedicated space embedded in an object to indicate whether the object is a primary object consists of a single bit.

4. The system of claim 1 , wherein the objects include a primary object Y having at least two secondary objects.

5. 2. The system of claim 1, wherein the objects include an object Z that is not a primary object, and object Z has no secondary objects and no embedded references.

6. The system of claim 1 , wherein the objects include a secondary object Q that is also a primary object.

7. The following method, i.e. At most 10 percent of the objects in a program that is at least partially executed within said system are primary objects; or a program at least partially executed within said system having at least 10,000 objects, each of which object X has an individual embedded dedicated space of not more than 4 bits to indicate whether said object X is a primary object, and no embedded dedicated space of more than 4 bits to identify any other object as a secondary object of said object X; The system of claim 1 further characterized by at least one of the following:

8. A method for memory management using secondary objects, the method comprising: indicating whether each of a plurality of objects is a primary object in a private space embedded within the plurality of objects, each private space being smaller than an object reference, a primary object being an object that has at least one secondary object, the secondary object being considered live by garbage collection if the primary object is live even if the secondary object is not a reference object of the primary object; treating secondary objects as reference objects by marking as live at least both (i) all reference objects of each live object X, and (ii) all secondary objects of each live object X during garbage collection marking; To avoid embedding any reference-sized space for holding references to secondary objects within objects that are not primary objects; A method comprising:

9. During garbage collection marking, Following the code paths shared by the marking of secondary objects and the marking of reference objects, at least to the extent that individual objects are checked for liveness; or Following the code paths shared by secondary object marking and reference object marking, at least to the extent that object references are enumerated to support checking individual objects for liveness. The method of claim 8 , further comprising at least one of:

10. During garbage collection marking, avoiding reliance on looping through a handle table containing non-primary objects to collect secondary object handles; or Avoiding reliance on the value of a liveness promotion counter to collect secondary object handles The method of claim 8 , further comprising at least one of:

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

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

13. using a data structure to specify that object X and object Y are each secondary objects of primary object Z; Marking each reference object of object X and marking each secondary object of object X to treat the secondary object X as a primary object in its own right. The method of claim 8 , further comprising at least one of:

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

15. the method includes following a reference object marking code path for marking reference objects during garbage collection, and following a secondary object marking code path for marking secondary objects during the garbage collection; 9. The method of claim 8, wherein at least 50 percent of the reference object marking code path overlaps with the secondary object marking code path, the overlap being measured under at least one of the following overlap metrics: lines of code, number of instructions generated by a compiler, number of routines called, or number of stack frames.

16. 1. A computer-readable storage medium comprising data and instructions that, when executed by a processor, cause a computing device to perform a method for memory management using secondary objects, the method comprising: indicating whether each of a plurality of objects is a primary object in a private space embedded within the plurality of objects, each private space being smaller than an object reference, a primary object being an object that has at least one secondary object, the secondary object being considered live by garbage collection if the primary object is live even if the secondary object is not a reference object of the primary object; treating secondary objects as reference objects by marking as live at least both (i) all reference objects of each live object X, and (ii) all secondary objects of each live object X during garbage collection marking; avoiding embedding any reference-sized space for holding references to secondary objects within objects that are not primary objects, each reference-sized space being at least 32 bits in size; 23. A computer-readable storage medium comprising:

Images