is it possible/feasable to run the garbage collector in its own thread, so the slowdown doesn't cause the application to temporarily freeze?

If so, would i just use std.thread?

thx.

On Tue, 05 Apr 2005 23:46:33 -0400, clayasaurus <clayasaurus@gmail.com> wrote:
> is it possible/feasable to run the garbage collector in its own thread, so the slowdown doesn't cause the application to temporarily freeze?
>
> If so, would i just use std.thread?

What "slowdown"? IIRC the garbage collector pauses all threads when doing a collect. That may be the "freeze" you're talking about?

Regan

Regan Heath wrote:
> On Tue, 05 Apr 2005 23:46:33 -0400, clayasaurus <clayasaurus@gmail.com>  wrote:
> 
>> is it possible/feasable to run the garbage collector in its own thread,  so the slowdown doesn't cause the application to temporarily freeze?
>>
>> If so, would i just use std.thread?
> 
> 
> What "slowdown"? IIRC the garbage collector pauses all threads when doing  a collect. That may be the "freeze" you're talking about?
> 
> Regan

I just re-tested my program.

Before I had frame based movement (which moves the object based on the amount of time between the frames), the chugging was very noticable. Now it is not so.

In the back of my mind I am afraid of the garbage collector chugging in the background, making the program run at a slower speed every so often, which is annoying.

I guess you can tell I don't know much about GC, and was wondering if what I asked was even possible. Seeing as GC pauses all threads, I guess not?

Oh well, the GC is a love/hate relationship I guess. I will use it, because I am even more afraid D will become unstable and crash without it. (i was getting weird random crashings)

I'm making a little opengl game, btw.

On Wed, 06 Apr 2005 00:22:26 -0400, clayasaurus <clayasaurus@gmail.com> wrote:
> Regan Heath wrote:
>> On Tue, 05 Apr 2005 23:46:33 -0400, clayasaurus <clayasaurus@gmail.com>  wrote:
>>
>>> is it possible/feasable to run the garbage collector in its own thread,  so the slowdown doesn't cause the application to temporarily freeze?
>>>
>>> If so, would i just use std.thread?
>>   What "slowdown"? IIRC the garbage collector pauses all threads when doing  a collect. That may be the "freeze" you're talking about?
>>  Regan
>
> I just re-tested my program.
>
> Before I had frame based movement (which moves the object based on the amount of time between the frames), the chugging was very noticable. Now it is not so.
>
> In the back of my mind I am afraid of the garbage collector chugging in the background, making the program run at a slower speed every so often, which is annoying.
>
> I guess you can tell I don't know much about GC, and was wondering if what I asked was even possible. Seeing as GC pauses all threads, I guess not?
>
> Oh well, the GC is a love/hate relationship I guess. I will use it, because I am even more afraid D will become unstable and crash without it. (i was getting weird random crashings)
>
> I'm making a little opengl game, btw.

I think the general rule for "real time" applications is "Don't allocate anything and the GC wont collect". As soon as you allocate memory, the GC might decide to collect in order to free memory.

OT: kinda like a debt collector, dont buy stuff, and he wont pay you a visit.

Regan

> Before I had frame based movement (which moves the object based on the amount of time between the frames), the chugging was very noticable. Now it is not so.

You can call std.gc.getStats to get information about the state of the GC. Printing the stats as you run will give you an idea when the GC is collecting or what it is doing. Since the GC in dmd stops the world when it collects I would guess that it would run fast for a while and then have a hiccup as it collects and then run fast again for a while more. The hiccups will depend on how much garbage the code generates. Obviously the less you can generate the better the performance.

> In the back of my mind I am afraid of the garbage collector chugging in the background, making the program run at a slower speed every so often, which is annoying.

The boehm collector has an "incremental" version which will smooth out the behavior so that you won't get any hiccups. If you are feeling adventurous check out http://wxd.sourceforge.net/misc.html

> I guess you can tell I don't know much about GC, and was wondering if what I asked was even possible. Seeing as GC pauses all threads, I guess not?
>
> Oh well, the GC is a love/hate relationship I guess. I will use it, because I am even more afraid D will become unstable and crash without it. (i was getting weird random crashings)

An incremental collector and an eye on the amount of garbage generated goes a long way to removing any user noticable effects of the GC.

clayasaurus wrote:
> Regan Heath wrote:
> 
>> On Tue, 05 Apr 2005 23:46:33 -0400, clayasaurus <clayasaurus@gmail.com>  wrote:
>>
>>> is it possible/feasable to run the garbage collector in its own thread,  so the slowdown doesn't cause the application to temporarily freeze?
>>>
>>> If so, would i just use std.thread?
>>
>>
>>
>> What "slowdown"? IIRC the garbage collector pauses all threads when doing  a collect. That may be the "freeze" you're talking about?
>>
>> Regan
> 
> 
> I just re-tested my program.
> 
> Before I had frame based movement (which moves the object based on the amount of time between the frames), the chugging was very noticable. Now it is not so.
> 
> In the back of my mind I am afraid of the garbage collector chugging in the background, making the program run at a slower speed every so often, which is annoying.
> 
> I guess you can tell I don't know much about GC, and was wondering if what I asked was even possible. Seeing as GC pauses all threads, I guess not?
> 
> Oh well, the GC is a love/hate relationship I guess. I will use it, because I am even more afraid D will become unstable and crash without it. (i was getting weird random crashings)
> 
> I'm making a little opengl game, btw.
> 
> 

I am also working on a (not-so-little) game and to solve the problem of worrying about GC slowing things down, I'm simply avoiding using it.
I have an object pool that objects are sent to rather than being left for collection, then when my program has a few cycles, it will free some of the objects up. Well, not always, since I also want to avoid allocating objects, rather than using "new" to get a new object, you request one from the pool, which, if it has one in memory, will give it back to you. So after an initial startup, there should be neither allocation or collection, except when memory space starts getting tight.

The fun part of it all is minimizing the allocating of the storage classes used to store objects in the pool by having a separate mini-pool of these. I'm not really sure if this is completely necessary, but I do want to avoid doing allocation as much as possible.

I guess this approach is somewhere halfway between garbage collection and manual memory management. I'm used to just doing all my own memory management in C++, so it shouldn't be too bad. Plus I'm watching out from the beginning for memory leaks and such, so I should catch anything early on.

Anyway, I've put enough here about this. I'll let you know how this approach works.

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch