www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - garbage collector in seperate thread?

reply clayasaurus <clayasaurus gmail.com> writes:
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.
Apr 05 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Apr 05 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
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.
Apr 05 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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
Apr 05 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 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.
Apr 06 2005
prev sibling parent Paul Bonser <misterpib gmail.com> writes:
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
Apr 20 2005