R
Roger Pack
All righty. Here is a patch for anyone adventurous [a diff against ruby
1.9 SVN HEAD]
It runs the garbage collector in a child process--the child discovers
any garbage and reports back which objects have no references to them
[or rather, HAD no references to them--at the time the child was forked]
so the parent basically does little of the garbage collection. It's
like it gets a premonition hint to the parent "here are all the freeable
objects!"
http://gist.github.com/18242
limitations:
currently doesn’t actually ever free any heaps–[but this turns out to
not be a problem--Ruby never seems to, anyway].
currently works on OS X [sorry]
Note that it adds some extra printfs to the GC, so you may have to run
'make' a few times till it succeeds, since this confuses it slightly.
Note 2: output explanation:
The child currently tries to finish the GC "before the parent runs out
of freelist" -- if it runs out the parent waits for the GC child to
finish before continuing.
If it outputs "receiving WELL" this means that the child thread finished
"on time" and the parent didn't have to pause at all. If it outputs
"receiving POORLY" this means that the freelist ran out and the spawned
GC wasn't as effective as the parent had to pause to wait for it.
speed:
I’ve had some things speed up. Try it out if adventuresome.
Feedback welcome.
-=R
1.9 SVN HEAD]
It runs the garbage collector in a child process--the child discovers
any garbage and reports back which objects have no references to them
[or rather, HAD no references to them--at the time the child was forked]
so the parent basically does little of the garbage collection. It's
like it gets a premonition hint to the parent "here are all the freeable
objects!"
http://gist.github.com/18242
limitations:
currently doesn’t actually ever free any heaps–[but this turns out to
not be a problem--Ruby never seems to, anyway].
currently works on OS X [sorry]
Note that it adds some extra printfs to the GC, so you may have to run
'make' a few times till it succeeds, since this confuses it slightly.
Note 2: output explanation:
The child currently tries to finish the GC "before the parent runs out
of freelist" -- if it runs out the parent waits for the GC child to
finish before continuing.
If it outputs "receiving WELL" this means that the child thread finished
"on time" and the parent didn't have to pause at all. If it outputs
"receiving POORLY" this means that the freelist ran out and the spawned
GC wasn't as effective as the parent had to pause to wait for it.
speed:
I’ve had some things speed up. Try it out if adventuresome.
Feedback welcome.
-=R