public class HeapChunk extends Object
A HeapChunk is not a normal Object, so can't be allocated/constructed/initialized using new. A HeapChunk is raw memory with a HeapChunk.Header on the beginning that keeps bookkeeping information about the HeapChunk. HeapChunks do not have any instance methods: instead they have static methods that take the HeapChunk.Header as a parameter.
HeapChunks maintain Pointers to the current allocation point (top) with them, and the limit (end) where Objects can be allocated. Subclasses of HeapChunks can add additional fields as needed.
HeapChunks maintain some fields that would otherwise have to be maintained in per-HeapChunk memory by the Space that contains them. For example, the fields for linking lists of HeapChunks in a Space is kept in each HeapChunk rather than in some storage outside the HeapChunk.
For fields that are maintained as more-specifically-typed Pointers by leaf "sub-classes", HeapChunk defines the generic (Pointer) "get" methods, and only the "sub-classes" define "set" methods that store more-specifically-typed Pointers, for type safety.
Some things that seem like they should be field access instead just compute (rather than store) Pointers. For example, the start of where Objects can be allocated within a HeapChunk depends on the size of the Header for the HeapChunk, which depends on the layout of the various leaf "sub-classes" of HeapChunk. If HeapChunk were a regular Java object, the method that returned the Pointer to "start" might be declared as an abstract virtual method, but HeapChunk does not have methods like that, so each leaf class declares a static method to return "start". Virtual method access can be provided by, for example, AlignedHeapChunk.getAlignedHeapChunkStart(AlignedHeapChunk.AlignedHeader) and UnalignedHeapChunk.getUnalignedStart(UnalignedHeapChunk.UnalignedHeader).
In addition to the declared fields of a HeapChunk.Header, for example, a CardRememberedSetHeapChunk keeps a card table for the write barrier, but because they are variable-sized, rather than declaring field in the Header, static methods are used to compute Pointers to those "fields".
HeapChunk could have a private constructor to prevent instances from being created, but that prevents sub-classing HeapChunk and the inheritance of the static methods defined here.
HeapChunks are *not* examined for interior Object references by the collector, though the Objects allocated within the HeapChunk are examined by the collector.
| Modifier and Type | Class and Description |
|---|---|
static interface |
HeapChunk.Header<T extends HeapChunk.Header<T>> |
static class |
HeapChunk.MemoryWalkerAccessImpl<T extends HeapChunk.Header<?>>
Shared methods for a MemoryWalker to access a heap chunk.
|
| Constructor and Description |
|---|
HeapChunk() |
| Modifier and Type | Method and Description |
|---|---|
protected static org.graalvm.word.Pointer |
asPointer(HeapChunk.Header<?> that)
Convenience method: Cast a
HeapChunk.Header to a Pointer to allow address arithmetic. |
static org.graalvm.word.UnsignedWord |
availableObjectMemory(HeapChunk.Header<?> that)
How much space is available for objects in a HeapChunk?
|
protected static void |
setTopCarefully(HeapChunk.Header<?> that,
org.graalvm.word.Pointer newTop)
Set top, being careful that it is between the current top and end.
|
static boolean |
walkObjectsFrom(HeapChunk.Header<?> that,
org.graalvm.word.Pointer offset,
ObjectVisitor visitor)
Apply an ObjectVisitor to all the Objects in the given HeapChunk.
|
public static boolean walkObjectsFrom(HeapChunk.Header<?> that, org.graalvm.word.Pointer offset, ObjectVisitor visitor)
public static org.graalvm.word.UnsignedWord availableObjectMemory(HeapChunk.Header<?> that)
protected static void setTopCarefully(HeapChunk.Header<?> that, org.graalvm.word.Pointer newTop)
protected static org.graalvm.word.Pointer asPointer(HeapChunk.Header<?> that)
HeapChunk.Header to a Pointer to allow address arithmetic.