• Craig Black (8/8) Apr 10 2006 Given the current state of things, garbage collection could cause dramat...
• Mike Capp (9/16) Apr 10 2006 I don't see how. Any estimate made before the GC starts would be very cr...
• Craig Black (5/15) Apr 10 2006 Indeed, you would have to be careful to not allocate memory on the heap....
• Frank Benoit (2/5) Apr 10 2006 The main problem is the moving reference. Without that problem, it would
• Craig Black (2/4) Apr 10 2006 I don't know a lot about GC. What is the moving reference?
• Frank Benoit (8/16) Apr 10 2006 - start of gc collecting cycle
• Craig Black (4/11) Apr 10 2006 Hmmm. I don't see this as a showstopper. Just avoid assigning referenc...

"Craig Black" <cblack ara.com> writes:

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 

Mike Capp <mike.capp gmail.com> writes:

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

"Craig Black" <cblack ara.com> writes:

 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

Frank Benoit <benoit__ __tionex.de> writes:

 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.

"Craig Black" <cblack ara.com> writes:

 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 

Frank Benoit <benoit__ __tionex.de> writes:

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!

"Craig Black" <cblack ara.com> writes:

 - 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