One of the points made on /. recently was about garbage collection being anathema to real time programming. Given that RT is a subset of the system programming arena at which D is targeted, I'd like to know how D gets around this apparent contradiction.

Something I always wanted in Java was a way of forcing (not just suggesting) a run of the collector, and a way of turning it off for either a block of code or a thread entirely. Also a delete method that would collect just that object (and any that relied on it for survival). That way you could write tight code to run in real time and if the GC ever does run it quickly finds there is nothing to do. Of course there may be complications introduced from having some code/memory under the aegis of the collector and some not, but at least it should make more things possible.

Thanks for your time and any responses,
Andy Kirkpatrick

Andy Kirkpatrick wrote:
> One of the points made on /. recently was about garbage collection being
> anathema to real time programming. Given that RT is a subset of the system
> programming arena at which D is targeted, I'd like to know how D gets around
> this apparent contradiction.
> 
> Something I always wanted in Java was a way of forcing (not just suggesting) a
> run of the collector, and a way of turning it off for either a block of code or
> a thread entirely. Also a delete method that would collect just that object (and
> any that relied on it for survival). That way you could write tight code to run
> in real time and if the GC ever does run it quickly finds there is nothing to
> do. Of course there may be complications introduced from having some code/memory
> under the aegis of the collector and some not, but at least it should make more
> things possible.
> 
> Thanks for your time and any responses,
> Andy Kirkpatrick
> 
> 

One of the things I noticed about /. is that many of the responses tend to be knee-jerk reactions and uninformed.  Most of the people respond without having even given the D specs a cursory read.  :-(  Sorry, I just find some of the responses a little frustrating.

To answer your question, though, the garbage collector can be turned off and on at the programmer's whim, which would be useful in real time programming situations.  Take a look at gc.enable() and gc.disable description here:

http://www.digitalmars.com/d/memory.html

Of interest are the "Real Time" and "Smooth Operation" sections.

Hope you find D of interest. :-)

Later,

John Reimer

In article <c651tn$2cfr$1@digitaldaemon.com>, John Reimer says...
>Andy Kirkpatrick wrote:
>> One of the points made on /. recently was about garbage collection being anathema to real time programming. Given that RT is a subset of the system programming arena at which D is targeted, I'd like to know how D gets around this apparent contradiction.
>
>One of the things I noticed about /. is that many of the responses tend to be knee-jerk reactions and uninformed.  Most of the people respond without having even given the D specs a cursory read.  :-(  Sorry, I just find some of the responses a little frustrating.

Yeah /. has its share of that. I did read a lot of stuff about D a few years ago and forgot this detail, couldn't find it from a cursory search.

>To answer your question, though, the garbage collector can be turned off and on at the programmer's whim, which would be useful in real time programming situations.  Take a look at gc.enable() and gc.disable description here:

Excellent stuff!

>Hope you find D of interest. :-)

Always have, thanks :) I hope that D usage grows and the Open D project proceeds apace...

Cheers,
Andy Kirkpatrick

"Andy Kirkpatrick" <Andy_member@pathlink.com> wrote in message news:c65008$29m4$1@digitaldaemon.com...
> Also a delete method that would collect just that object (and
> any that relied on it for survival).

D has a 'delete' operator that does what you suggest (though it does not delete "any that relied on it for survival", as that would require a gc pass to determine).

> 
> Yeah /. has its share of that. I did read a lot of stuff about D a few years ago
> and forgot this detail, couldn't find it from a cursory search.
> 
> 

Argh, no blame to you, Andy.  This is the place to ask such stuff.  I was just venting about people on slash.dot that complain about or belittle D when they haven't investigated more.

Asking a question is a different thing.  Some of those answers are hard to dredge up, so that's what the newsgroup is for. :-)

<snip>

>>Hope you find D of interest. :-)
> 
> 
> Always have, thanks :) I hope that D usage grows and the Open D project proceeds
> apace...

Great!

Andy Kirkpatrick schrieb:
> One of the points made on /. recently was about garbage collection being
> anathema to real time programming. Given that RT is a subset of the system
> programming arena at which D is targeted, I'd like to know how D gets around
> this apparent contradiction.

We have a garbage collector plug-in interface. Escpecially interesting for more or less real-time tasks would be three-color garbage collector, which, as opposed to standard mark&sweep can run in the background, without stopping the main thread. In conservative implementation, as the one supported by the current interface, it would requiere OS to expose dirty bits on memory pages. Otherwise, it could be integrated by modifying the GCC-based compiler, though this would cost us some performance.

> Something I always wanted in Java was a way of forcing (not just suggesting) a
> run of the collector, and a way of turning it off for either a block of code or
> a thread entirely. Also a delete method that would collect just that object (and
> any that relied on it for survival). That way you could write tight code to run
> in real time and if the GC ever does run it quickly finds there is nothing to
> do. Of course there may be complications introduced from having some code/memory
> under the aegis of the collector and some not, but at least it should make more
> things possible.

The standard library (Phobos) has a simple interface which allows you to:

* run garbage collector - the function returns after it is finished.
* stop garbage collector - it will not interfere from then on, good for realtime sections.
* resume garbage collector - cancel the last one. It is likely that the garbage collector runs a scan when you resume it.

Besides, for standard mark&sweep collector, it is guaranteed that the language runtime only executes the collector during memory allocation requests. Of course, some application framework could override this behaviour, but else you can have a guarantee that in a single-threaded application your performance critical mode will not cause a garbage collector run because it should use memory allocated by the application in advance anyway.

It is technically not possible to turn off garbage collector for a selected thread, because all threads share a common heap, which has to be scanned completely with both mark&sweep and tricolor - i don't know whether there is some other garbage colection scheme. However, there is possibly some way of writing a thread which cannot be interrupted by a garbage collector and allocate memory the C way, by interfacing the OS directly. Cannot say much more about it though. Be aware that a standard C malloc can also pause for quite a while.

There is a delete statement, which explicitly deletes a garbage collector allocated array/memory or a class. If it is a class, it can take care of deleting any members in its destructor. Otherwise, it will be cleaned up by the garbage collector at the next scan, whenever that is. For performance reasons, you cannot requiere that delete direktly provokes a complete scan, since this is what is requiered to delete all unused members as well.

> Thanks for your time and any responses,
> Andy Kirkpatrick

After slashdotting we do need especially much time. Oh well. I guess it means something good.

-eye

Ilya Minkov wrote:

> We have a garbage collector plug-in interface. Escpecially interesting for more or less real-time tasks would be three-color garbage collector, which, as opposed to standard mark&sweep can run in the background, without stopping the main thread. 

It would be nice to have a few GC's like this to pick from, like in DTL.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Ilya Minkov wrote:
> 
>> We have a garbage collector plug-in interface. Escpecially interesting for more or less real-time tasks would be three-color garbage collector, which, as opposed to standard mark&sweep can run in the background, without stopping the main thread. 
> 
> 
> It would be nice to have a few GC's like this to pick from, like in DTL.
> 
Have a look at these names:

 Baker's real time copying collection
 Bartlett's conservative-compacting collection
 Treadmill collection
 Goldberg's tagless collection
Appel-Ellis-Li Collector* -> Baker's++
Baker's Treadmill

These are all names of GC algorithms. The last two ones were especially interesting.
The Appel-Ellis-Li Collector is an Copying Collector based on Baker's one. Baker's Treadmill uses some structure that can be interpreted like a wheel. It's one of those three color GC's Minkov mentioned.

How is garbage collection handled across threads?

If one thread allocated an object, and another thread holds on to the memory until it is done, which is a pretty normal thing to do, the garbage collector has to be system (or process) wide and not per-thread.  So when one thread needs memory for an object it can trigger the GC.  But another thread might be in a time-critical place.  This only means that all the threads in a process need to use the same memory management discipline.

This will limit the degree to which you can import code and tools from other libraries.  Eventually you are going to want to be able to delay choosing the memory management discipline until run time.  The memory management discipline would be a trait (or maybe an aspect). I don't know of any language that can do this, although the "Allocators" in some C++ template classes might try, for all I know.

What's the D answer to this?

"Warren" <warrens@seanet.com> wrote in message news:c67kil$ods$1@digitaldaemon.com...
> How is garbage collection handled across threads?

All threads are paused during the gc pass.