So, how about:

  delete foo;  // decrement reference count and possibly delete

  delete;      // or "compact;" -- force GC to run

...and it's up to the programmer to make sure there's only one reference if he wants the delete to really work. That way things are safe, but the programmer can still force a release or a GC pass.

-Russell B

I intend for there to be a class in the runtime library called "GC" or some such through which you can tune the behavior of the garbage collector.

unfortunately specifications says:

>Who D is Not For

>     Real time programming where latency must be guaranteed.
>...

for me it is not a goo news as D seems nice

Roland


Kent Sandvik a écrit :

> "Michael Gaskins" <mbgaski@clemson.edu> wrote in message news:9li8re$npb$1@digitaldaemon.com...
> > Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've
> just
> > started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC
> routines
> > should still be implemented, but it would be nice to also be able to initiate the process manually.
>
> For real-time intensive tasks, if one could also enforce that the GC should not run for a certain section, maybe that would also help out. It's true it would cause performance problems later, but it gives more power in case there's a section in the code where GC would cause problems, especially with timing issues and such. --Kent

Roland wrote:
> 
> unfortunately specifications says:
> 
> >Who D is Not For
> 
> >     Real time programming where latency must be guaranteed.
> >...
> 
> for me it is not a goo news as D seems nice
> 
> Roland

	Along these lines, is the garbage collector the only reason D cannot be
used for real-time?  It seems to me that depending on how much control
the programmer can get to how GC behaves (I thought Walter mentioned a
module to tune it) that D could still be reasonable for multi-media and
other non critical apps that often use real-time scheduling right?
Given the ability to use delete (carefully!) D might not be so bad.
There are still temp values from expressions that need cleaning.
	Also, an I understand GC right to believe that, for the most part, you
can stop a GC sweep part way through and continue it later?  Does it
have to be atomic?

Dan

Dan Hursh <hursh@infonet.isl.net> writes:

> 	Also, an I understand GC right to believe that, for the most part, you
> can stop a GC sweep part way through and continue it later?  Does it
> have to be atomic?

No, it doesn't.  If you're using a mark-and-sweep collector, the sweep phase is rather uncritical anyway, sweeping can be interleaved with normal execution.  For the mark phase, things are more complicated, of course, but there are certainly more options than just halting the mutator.  AFAIK, recent versions of the Boehm collector (a probabilistic collector for C) support concurrent marking on some architectures.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Walter wrote:

> Yes, you are absolutely right. D has a "delete" operator, that explicitly tells the gc that this memory can be free'd now and there's no need to wait until the next gc cycle. It'd be up to the programmer, however, to guarantee that there'd be no dangling references to the memory, so it isn't perfect :-(

How about this as a safer syntax:

gc <statement>
  EXAMPLE:
int[] buf = new int[10000];
...
gc buf = foo();

Any statement prefixed with gc will cause immediate garbage collection on any references lost as part of that statement.  That is, the reference to the 10,000 member int array is lost in the last statement, so it is immediately garbage-collected when the statement completes (or, perhaps, immediately when the last reference is lost).  My general inclination is to say that this statement shouldn't affect the performance of foo(), though that's not absolute.

Another idea would be to use delete, but have it only valid on lvals.  It would set the value of that variable to null, then check to see if any references remain.  If so, no garbage collection happens.  If not, garbage collection happens immediately.

int[123456] buf;
int *ptr = buf;
delete buf; /* buf is set to null here, but the buffer is NOT cleaned up */
delete ptr; /* ptr is set to null, and its reference is immediately cleaned up
*/

Of course, I'm not 100% sure that any such syntax is needed at all.  Perhaps it's enough to just be able to force a garbace collection.  Just force one whenever you delete something that you think might be unnaturally large.

Thoughts?

It would not be too practical to scan all of memory for references to just one object - you might as well do a full gc.

The purpose of a specific delete is:

1) Get the destructor for the object run right now
2) Aid the GC

Russ Lewis wrote in message <3B97E8EB.1B363F4F@deming-os.org>...
>Walter wrote:
>
>> Yes, you are absolutely right. D has a "delete" operator, that explicitly tells the gc that this memory can be free'd now and there's no need to
wait
>> until the next gc cycle. It'd be up to the programmer, however, to
guarantee
>> that there'd be no dangling references to the memory, so it isn't perfect :-(
>
>How about this as a safer syntax:
>
>gc <statement>
>  EXAMPLE:
>int[] buf = new int[10000];
>...
>gc buf = foo();
>
>Any statement prefixed with gc will cause immediate garbage collection on
any
>references lost as part of that statement.  That is, the reference to the
10,000
>member int array is lost in the last statement, so it is immediately garbage-collected when the statement completes (or, perhaps, immediately
when
>the last reference is lost).  My general inclination is to say that this
>statement shouldn't affect the performance of foo(), though that's not
absolute.
>
>Another idea would be to use delete, but have it only valid on lvals.  It
would
>set the value of that variable to null, then check to see if any references remain.  If so, no garbage collection happens.  If not, garbage collection happens immediately.
>
>int[123456] buf;
>int *ptr = buf;
>delete buf; /* buf is set to null here, but the buffer is NOT cleaned up */
>delete ptr; /* ptr is set to null, and its reference is immediately cleaned
up
>*/
>
>Of course, I'm not 100% sure that any such syntax is needed at all.
Perhaps
>it's enough to just be able to force a garbace collection.  Just force one whenever you delete something that you think might be unnaturally large.
>
>Thoughts?
>

Walter wrote:

> It would not be too practical to scan all of memory for references to just one object - you might as well do a full gc.
>
> The purpose of a specific delete is:
>
> 1) Get the destructor for the object run right now
> 2) Aid the GC

In a subjective sense, how expensive is the GC routine, and how much backlog is likely to happen?  I'm not convinced that it's a bad thing to just force a complete run of the GC when you need to guarantee cleanup right now.

At least the a wide spread implementation of the  boehm-demers-weiser gc implementation ( http://www.hpl.hp.com/personal/Hans_Boehm/gc/ )

allows you also to specifically delete an object when you want it with GC_free()

It allows you also to register "finalizers" with objects that are run when they are destructed.

- Axel

Walter wrote:

> It would not be too practical to scan all of memory for references to just one object - you might as well do a full gc.
>
> The purpose of a specific delete is:
>
> 1) Get the destructor for the object run right now
> 2) Aid the GC

I have no experience with (implementations of) GC, so I don't know how it works.  Maybe we could have a few details?  My assumptions were based on the thought that the algorithm would work something like this:

* Maintain a reference count on each GC-able object.
* When assigning a pointer (or array), first take the old value and put it in a
list of objects to consider for the GC.  You normally would only do this when
the reference count goes to 0, but you have to consider circular references that
are not accessible from the main tree.
* When the GC runs, it just iterates down the list of recently released objects;
when it finds one with 0 references (or with only circular references), it
automatically calls the destructor.

However, you talk about "scanning" which sounds like a different algorithm altogether, so I'm stumped...  I'm hoping you don't mean that you're scanning through all of memory for pointers to an object (eek!)