Last update September 21, 2007

Doc Comments /
Memory



Difference (last change) (no other diffs, normal page display)

Added: 7a8,13

=== 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).



Deleted: 77,79d82
== Amendments =
You may add a link to this page on the DocumentationAmendments page to draw extra attention to your suggestion.


Changed: 81c84,86
See the corresponding page in the D Specification: DigitalMars:d/memory.html
Corresponding page in the D Specification:
* D 1.0
* D 2.0

Memory Management    

Table of contents of this page
Memory Management   
Messages   
Allocating Class Instances On The Stack   
Realtime Garbage Collection   
Using the C head with D   
root pointer scanning?   
What about interrupt handlers?   
builtin array allocates   
Links   

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

    http://reports-archive.adm.cs.cmu.edu/cs2001.html

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.):

  1. 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.
  2. 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).
  3. If struct pointers allocated with the C heap are not registered with the GC, then all members must use the C heap as well.
  4. All classes allocated with the C heap should be registered with the GC because they can be derived from.
  5. 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.

Couldn't the compiler simply determine which pointers are actually on the stack and register them once at the start of the program?

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:
FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: September 21, 2007 17:05 (diff))