Now you know you can.
|2) a GC that is ‘user-definable’ (run after this definable threshold,
|this often), and (asidedbly), a GC that can run in its own (native)
|thread so it doesn’t pause execution of normal threads.
I’d rather prefer smarter collector, but it’s possible.
GC on its own thread is a different story. Interaction between
collector and mutator may hinder the performance.
Would the following be a good idea?
When you garbage collect, fork and have the child “check for garbage”
then report back to the parent on which objects are no longer used.
Children and parents can share memory, it appears .
So my thought would be to have the parent and child share a “freeable”
When the parent runs out of memory it spawns a child to do garbage
collection, and continues running. The child would propagate a shared
[large’ish] “freeable” list with pointers to memory which is no longer
used. The parent would later notice GC completion through some message,
and then reclaim the memory and free any unused blocks, and reap the
My hypothesis is that this would allow for a single script to execute
faster, especially on dual core machines when only one script is running
[the child could run in the other core]. This would theoretically then
[should it work]: cost more RAM, use about the same total CPU, but allow
the script to continue running [a la macruby] during GC. Should you
have multiple cores available, it should have shorter execution time,
which is, after all, what we’re after.