Given the current state of things, garbage collection could cause dramatic pauses.  Is there any way that the garbage collector could have some delegate to post its progress?  The delegate would be invoked passing the estimated length of time it will take to perform the collection, say once every second or once every half a second.  This allow the application to post the progress to give the user feedback as to what is happening and how long it is going to take.

-Craig

In article <e1e9rp$5tp$1@digitaldaemon.com>, Craig Black says...
>
>Given the current state of things, garbage collection could cause dramatic pauses.  Is there any way that the garbage collector could have some delegate to post its progress?  The delegate would be invoked passing the estimated length of time it will take to perform the collection, say once every second or once every half a second.  This allow the application to post the progress to give the user feedback as to what is happening and how long it is going to take.

I don't see how. Any estimate made before the GC starts would be very crude. Probably no better than assuming that it'll take as long as it did last time, and you can do that yourself.

Estimates partway through the collection might be more accurate, but not very useful, since you probably can't do very much with them without potentially invalidating all the work the GC has done so far.

cheers
Mike

> I don't see how. Any estimate made before the GC starts would be very
> crude.
> Probably no better than assuming that it'll take as long as it did last
> time,
> and you can do that yourself.

A crude estimate is better than none at all.

> Estimates partway through the collection might be more accurate, but not
> very
> useful, since you probably can't do very much with them without
> potentially
> invalidating all the work the GC has done so far.

Indeed, you would have to be careful to not allocate memory on the heap. Beyond this, I don't think there would be any limitations.  There are plenty of things that you can do to provide feedback without allocating memory.

-Craig

> Indeed, you would have to be careful to not allocate memory on the heap. Beyond this, I don't think there would be any limitations.  There are plenty of things that you can do to provide feedback without allocating memory.

The main problem is the moving reference. Without that problem, it would be much easier to make a concurrent gc not interrupting the program.

> The main problem is the moving reference. Without that problem, it would be much easier to make a concurrent gc not interrupting the program.

I don't know a lot about GC.  What is the moving reference?

-Craig

Craig Black schrieb:
>> The main problem is the moving reference. Without that problem, it would be much easier to make a concurrent gc not interrupting the program.
> 
> I don't know a lot about GC.  What is the moving reference?
> 
> -Craig
> 
> 

- start of gc collecting cycle
- gc scans refb, which is null
- gc calls your delegate
- in your delegate refb = refa; refa = null;
- your delegate ends, gc continues ('thinking' refb is null)
- scans refa, which is now null also
-> GC: Oh, no ref to obj, I can free it!

> - start of gc collecting cycle
> - gc scans refb, which is null
> - gc calls your delegate
> - in your delegate refb = refa; refa = null;
> - your delegate ends, gc continues ('thinking' refb is null)
> - scans refa, which is now null also
> -> GC: Oh, no ref to obj, I can free it!

Hmmm.  I don't see this as a showstopper.  Just avoid assigning references when providing feedback.  (Use of the GC delegate would be for advanced users anyway.)

-Craig