A few questions for Walter (or somebody who's studied his GC code):

1) I assume that the GC will run when we run out of memory.  Does it
ever run at other times, like perhaps during an idle condition or on a
timer?  If not, then I assume that the user could program such a
mechanism if he so desired...
2) Would it be possible to devise a timeout on the GC, so that it would
have an upper limit on its runtime?  If so, and if the GC were to
timeout, then do we really gain any useful information, or do we have to
start over next time totally from scratch?  That is, could several short
runs of the GC clean up a large block of garbage, or must it be one long
run?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF790DC.BB8EFFC0@deming-os.org...
> 1) I assume that the GC will run when we run out of memory.  Does it ever run at other times, like perhaps during an idle condition or on a timer?  If not, then I assume that the user could program such a mechanism if he so desired...

The gc runs in preference to increasing the size of the memory pool.

> 2) Would it be possible to devise a timeout on the GC, so that it would have an upper limit on its runtime?  If so, and if the GC were to timeout, then do we really gain any useful information, or do we have to start over next time totally from scratch?  That is, could several short runs of the GC clean up a large block of garbage, or must it be one long run?

You're thinking of incremental garbage collection, which is a very complicated thing to do successfully, and in my not-so-humble-opinion (!) not worth the effort and bugs.

The current gc is a simple mark and sweep algorithm. A future version will be generational, which will improve performance.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF790DC.BB8EFFC0@deming-os.org...
> > 1) I assume that the GC will run when we run out of memory.  Does it ever run at other times, like perhaps during an idle condition or on a timer?  If not, then I assume that the user could program such a mechanism if he so desired...
>
> The gc runs in preference to increasing the size of the memory pool.

I'm not sure I understand what that means.  Does that mean that you'll first run the gc before asking for more blocks of memory from the OS?  If so, how large of a block do you ask for at a time (a page?), and is there a way to tune this?

> > 2) Would it be possible to devise a timeout on the GC, so that it would have an upper limit on its runtime?  If so, and if the GC were to timeout, then do we really gain any useful information, or do we have to start over next time totally from scratch?  That is, could several short runs of the GC clean up a large block of garbage, or must it be one long run?
>
> You're thinking of incremental garbage collection, which is a very complicated thing to do successfully, and in my not-so-humble-opinion (!) not worth the effort and bugs.

I figured that that was the answer, but it was worth asking :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF7D9FA.5B9C5B81@deming-os.org...
> Walter wrote:
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF790DC.BB8EFFC0@deming-os.org...
> > > 1) I assume that the GC will run when we run out of memory.  Does it ever run at other times, like perhaps during an idle condition or on a timer?  If not, then I assume that the user could program such a mechanism if he so desired...
> > The gc runs in preference to increasing the size of the memory pool.
> I'm not sure I understand what that means.  Does that mean that you'll
first
> run the gc before asking for more blocks of memory from the OS?

Yes.

>  If so, how
> large of a block do you ask for at a time (a page?), and is there a way to
> tune this?

Those are all constants in gc.d.