Oracle International Corporation

Per A Liden

Stefan Mats Rikard Karlsson

Erik Österlund

A global state associated with a garbage collection (GC) process is a state assumed by a reference after GC operations for a current GC phase are performed for the reference. A frame state of a frame on a call stack of an application thread tracks a progress of GC operations for references therein. A color watermark is added after a global state change. The frame originally marked by a stack watermark is now marked by the new color watermark. The new color watermark marks a deepest frame on the call stack having the old global state. A color watermark is deleted when the stack watermark meets the color watermark. If the stack watermark is shifted in the call stack to mark the same frame as a color watermark, then the color watermark is deleted. The marked frame is a deepest frame on the call stack having the current global state.

Tracking frame states of call stack frames including colorless roots

A request is received, from a mutator thread, to load a first reference to a first object from a heap memory onto a call stack of the application thread. Responsive to receiving the request, a system retrieves the first reference from the heap memory. The system executes a bitwise shift operation that (a) removes one or more bits representing the first garbage collection state and (b) generates a second reference from the first reference. Based on a particular bit, of the one or more bits removed from the first reference by the shift operation, the system determines whether to perform a set of garbage collection operations on the first reference to bring the first reference to a good state. The second reference, without any indication of any of the plurality of garbage collection states, is stored to the call stack.

Colorless roots implementation in Z garbage collector

During execution of garbage collection marking, an application thread receives a first request to overwrite a reference field of an object, the object comprising at least a first reference and the first request comprising a second reference to be written to the reference field. Responsive to receiving the first request, the application thread determines a marking parity for objects being traversed by the garbage collection marking process and loads the first reference from the heap. The application thread determines that marking metadata of the first reference does not match the marking parity. Responsive to that determination, the application thread adds the first reference to a marking list, modifies the second reference to include the current marking parity as the marking metadata, and stores the modified second reference to the first reference field. In subsequent writes to the reference field, the application thread refrains from adding to the marking list.

Snapshot at the beginning marking in Z garbage collector

An application thread executes concurrently with a garbage collection (GC) thread traversing a call stack of the application thread. Frames of the call stack that have been processed by the GC thread assume a global state associated with the GC thread. The application thread may attempt to return to a target frame that has not yet assumed the global state. The application thread hits a frame barrier, preventing return to the target frame. The application thread determines a frame state of the target frame. The application thread selects appropriate operations for bringing the target frame to the global state based on the frame state. The selected operations are performed to bring the target frame to the global state. The application thread returns to the target frame.

Implementing state-based frame barriers to process colorless roots during concurrent execution

Garbage collection (GC) states are stored within references stored on a heap memory to track a progress of GC operations with respect to the references. GC state may be stored in a non-addressable portion of references. Based on the GC state of a particular reference, a set of GC operations are selected and performed for the reference. However, references stored on a call stack do not include any indication of GC state. Hence, loading a reference from heap to call stack involves removing the indication of GC state. Writing a reference to heap involves adding the indication of GC state. References embedded within a compiled method also do not indicate any GC state. Metadata of the compiled method indicate a GC state, which is implicated to the embedded references. GC operations are selected and performed for each embedded reference based on the GC state of the compiled method.

Tracking garbage collection states of references

During a concurrent Relocation Phase, a GC thread relocates live objects, as an application thread executes. References in a frame on a call stack are remapped if the application thread attempts to access the frame. References on the call stack remains stale if no application thread attempts access. The GC thread may proceed with a subsequent phase of a GC cycle, even if a frame has stale references and therefore has not assumed a remap state. During a concurrent Mark/Remap Phase, the call stack may include frames in different frame states. The GC thread selects appropriate operations for processing each frame based on the respective frame state. When the GC thread encounters a frame not in the remap state, references therein are first remapped, and then identified as roots. Hence, root reference remapping and identification are performed in a single concurrent phase of a GC cycle.

Consolidated and concurrent remapping and identification for colorless roots

During execution of garbage collection, an application receives a first request to overwrite a reference field of an object, the object comprising a first reference and the first request comprising a memory address at which the reference field is stored, and a second reference to be written to the reference field. Responsive to receiving the first request, the system determines a current remembered set phase, and loads the first reference. The application determines that remembered set metadata of the first reference does not match the current remembered set phase. Responsive to that determination, the application adds an entry to a remembered set data structure, modifies the second reference to include the current remembered set phase as the remembered set metadata, and stores the modified second reference to the reference field. In subsequent writes to the reference field, the application refrains from adding to the remembered set data structure.

Write barrier for remembered set maintenance in generational Z garbage collector

Techniques for performing garbage collection on an object array using array chunk references is described. A garbage collector (GC) thread identifies an object array to be processed. The GC thread divides the object array into array chunks. The GC thread generates array chunk references corresponding respectively to the array chunks. Each array chunk reference comprises: (a) chunk start bits representing a memory address of a start of a corresponding array chunk, and (b) chunk length bits representing a chunk length of the corresponding array chunk. The GC thread pushes the array chunk references onto the processing stack. A single processing stack concurrently stores multiple array chunk references, associated with a same object array. One or more of the array chunk references, that are associated with the same object array and stored on the processing stack, may be distributed to other GC threads for processing.

Performing garbage collection on an object array using array chunk references

The disclosed embodiments facilitate reusing both the physical and virtual memory in a garbage-collected computing environment immediately after a relocated memory area has been emptied, without using special hardware or operating system extensions. This system uses load barrier to perform fast checks to determine if a reference might point into a relocated memory area. If so, the load barrier performs further actions to remap pointers that actually point into the relocated memory area, without the need to read that memory. Because the system neither follows pointers into relocated memory areas nor protects relocated memory areas, the system can immediately reuse the virtual memory areas. The load barrier ensures that references pointing into a relocated memory area will be caught and handled, and references pointing into the newly allocated memory will pass through the barrier without further actions.

Growing community of inventors

Stockholm, Sweden

Per A Liden