View source code
Display the source code in core/memory.d from which this page was generated on
github.
Improve this page
Quickly fork, edit online, and submit a pull request for this page.
Requires a signed-in GitHub account. This works well for small changes.
If you'd like to make larger changes you may want to consider using
local clone.
Page wiki
View or edit the community-maintained wiki page associated with this page.
Module core.memory
This module provides an interface to the garbage collector used by applications written in the D programming language. It allows the garbage collector in the runtime to be swapped without affecting binary compatibility of applications.
Using this module is not necessary in typical D code. It is mostly useful when doing low-level memory management.
Notes to implementors
- On POSIX systems, the signals SIGUSR1 and SIGUSR2 are reserved by this module for use in the garbage collector implementation. Typically, they will be used to stop and resume other threads when performing a collection, but an implementation may choose not to use this mechanism (or not stop the world at all, in the case of concurrent garbage collectors).
- Registers, the stack, and any other memory locations added through
the
function are always scanned conservatively. This means that even if a variable is e.g. of typeGC.addRange
float
, it will still be scanned for possibleGC
pointers. And, if the word-interpreted representation of the variable matches aGC
-managed memory block's address, that memory block is considered live. - Implementations are free to scan the non-root heap in a precise
manner, so that fields of types like
float
will not be considered relevant when scanning the heap. Thus, casting aGC
pointer to an integral type (e.g.size_t
) and storing it in a field of that type inside theGC
heap may mean that it will not be recognized if the memory block was allocated with precise type info or with the
attribute.GC.BlkAttr.NO_SCAN
- Destructors will always be executed while other threads are active; that is, an implementation that stops the world must not execute destructors until the world has been resumed.
- A destructor of an
object
must not accessobject
references within theobject
. This means that an implementation is free to optimize based on this rule. - An implementation is free to perform heap compaction and copying
so long as no valid
GC
pointers are invalidated in the process. However, memory allocated with
must not be moved/copied.GC.BlkAttr.NO_MOVE
- Implementations must support interior pointers. That is, if the
only reference to a
GC
-managed memory block points into the middle of the block rather than the beginning (for example), theGC
must consider the memory block live. The exception to this rule is when a memory block is allocated with the
attribute; it is the user's responsibility to make sure such memory blocks have a proper pointer to them when they should be considered live.GC.BlkAttr.NO_INTERIOR
- It is acceptable for an implementation to store bit flags into
pointer values and
GC
-managed memory blocks, so long as such a trick is not visible to the application. In practice, this means that only a stop-the-world collector can do this. - Implementations are free to assume that
GC
pointers are only stored on word boundaries. Unaligned pointers may be ignored entirely. - Implementations are free to run collections at any point. It is, however, recommendable to only do so when an allocation attempt happens and there is insufficient memory available.
Structs
Name | Description |
---|---|
GC
|
This struct encapsulates all garbage collection functionality for the D programming language. |
Authors
Sean Kelly, Alex Rønne Petersen