Doc Comments /
Memory
Memory Management 
Messages
Allocating Class Instances On The Stack
The current docs are ambiguous, but apparently the bulleted items must all be true for a class to be allocated on the stack (
Issue:1521, NG:digitalmars.D/58947).
Realtime Garbage Collection
On http://www.digitalmars.com/d/memory.html you state:
"Real time programming means that a program must be able to guarantee a maximum latency, or time to complete an operation.
With most memory allocation schemes, including malloc/free and garbage collection, the latency is theoretically not bound[ed]."
This was true a decade or two ago.
It is not true today.
For example, see Perry Cheng's 2001 CMU PhD? thesis "Scalable Real-time Parallel Garbage Collection for Symmetric Multiprocessors", at bottom of page
where he demonstrates provable maximum latencies in the millisecond range using modern garbage collection technology on stock processors.
(He also discusses why "latency" is not the best measure of realtime capabilities.)
There will always be a place for manual storage allocation, just as there will always be a place for assembly language.
But today, for routine mainstream systems and application programming, manual storage allocation is rapidly becoming as passe' as manual register allocation: If you commit firmly to memory management techniques from the last millenium, you risk dooming D to footnote status. Time marches on!
Just my $0.02!
-- Cynbe"Stick to the Code." "The Code?" "He who falls behind -- is left behind." -- Pirates of the Caribbean
Using the C head with D
Some 'rules of thumb' for using the C heap with D (std.c.stdlib.malloc()/free(), etc.):
- The C heap can be used in D for non-aggregate native types (including class members) without special consideration of the GC. It is simply using a seperate heap.
- struct pointers allocated with the C heap can have GC'd members if the struct pointers are properly 'registered' with the GC (using gc.addRange() and gc.removeRange() - see the Explicit Class Instance Allocation example).
- If struct pointers allocated with the C heap are not registered with the GC, then all members must use the C heap as well.
- All classes allocated with the C heap should be registered with the GC because they can be derived from.
- When using the C heap, all of the normal C heap rules apply - anything malloc'd must be free'd, pointers should be zeroed, etc..
root pointer scanning?
The page contains: "scanning memory for root pointers into the garbage collected heap, the static data segment and the stack are scanned automatically".
Does this mean the garbage collector must scan the whole stack, testing whether a word has a value which *might* be an address in the heap, and if so, treats it, conservatively, as an actual heap address?
- Yes, it does mean that.
What about interrupt handlers?
You discuss how to handle latency in real time systems. But what about interrupt handlers (real hardware interrupts)? Does the GC have to turn off interrupts. If so how do I ensure my interrupt will be serviced in time? If the GC is interrupted the ISR could modify pointers and so invalidate the current (intermediate) results of the GC?
builtin array allocates
The placement form of builtin array allocates doesn't work:
char[] str = new(alloca(100))char[100]
Links
Corresponding page in the D Specification: