Browse Prior Art Database

Avoidance of object / memory leakage in Object Oriented systems incorporating Garbage Collection

IP.com Disclosure Number: IPCOM000184149D
Original Publication Date: 2009-Jun-12
Included in the Prior Art Database: 2009-Jun-12
Document File: 3 page(s) / 88K

Publishing Venue

IBM

Abstract

Disclosed is a system for avoiding the possibility of object / resource leakage when using a map to construct bespoke relationships between objects in an Object Oriented system utilising Garbage Collection (GC). This possibility is avoided by the use of a proposed standard facility provided by all objects in the system, by which a reference from one object to another may be established. Such a reference will ensure the lifetime of the object referred to (O2) will be at least equal to that of the object now holding the reference (O1).The relationship can then be externally recorded & recalled using a map in which references to both the key (O2) and the value (O1) are held "weakly" - i.e. in a manner by which GC may clear them.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Avoidance of object / memory leakage in Object Oriented systems incorporating Garbage Collection

[This page contains 102 pictures or other non-text objects]

Page 2 of 3

In an Object Oriented system, a relationship between one Object (O1) and another (O2) may, most simply, be recorded by storing a reference to O2 in a field in O1 (Figure 1).

    This both records the relationship between O1 and O2, and ensures, in a system incorporating Garbage Collection (GC), that O2 will not be GC'd whilst there are references (R1) from the rest of the system to O1.

    Also, if O2 is only referenced by O1, it allows O2 to be GC'd once all such references are released.

    This remains true even if O2 has direct or indirect references (R2) back to O1. In order to record the relationship in this manner, the designer / implementer of O1 must have considered and catered for the need to store such a relationship with O2.

    It is not generally practical for rely on the designer of a (particular type of) Object to have catered for every conceivable relationship that it may have with any other Object in any conceivable system (for all but the most trivial of examples).

    Arguably, it would be quite inefficient to do so, as each field in an Object increases the memory requirements of that Object, regardless of whether it is actually used.

    In practice, it is often the case that a relationship between O1 and O2 needs to be established that was not envisioned by the implementation of O1 (especially when interacting with 3rd party libraries).

    When this situation arises, the standard approach is to use a Map to record the relationship between the two objects, using O1 as the key and O2 as the value (Figure 2).

    However, doing so introduces references to O1 and O2 from the Map, which prevents either from being GC'd until all references to the Map (R3) are released.

    This modification to the GC eligibility, particularly of O1, is mostly undesirable. The standard approach to addressing this modification of GC eligibility is to hold the relationship between O1 and O2 in a WeakMap, where the reference to each key (O1) is held as a weak reference (Figure 3).

    (A weak reference is a special type reference understood by the GC: an Object that is only referred to by weak references, at the point where GC occurs, is eligible for GC.)

    (In addition, a WeakMap cleans up the entry in the Map once that entry's key has been GC'd).

    However, this approach only works so long as there is no direct or indirect reference from O2 bac...