On Thursday, 23 August 2012 at 14:38:19 UTC, Alex Rønne Petersen
wrote:
On 23-08-2012 15:21, Rory McGuire wrote:
On Thu, Aug 23, 2012 at 2:51 PM, dsimcha <dsim...@yahoo.com
<mailto:dsim...@yahoo.com>> wrote:
Basically, the idea is to store information about what is
and isn't
a pointer at the pool level instead of at the block level.
My
attempt from a long time ago at precise heap scanning, and
Antti-Ville's first attempt, stored meta-data at the end of
every
allocated block. This worked well for large arrays, but was
terribly inefficient for smaller allocations and made the
GC code
even messier than it already is. The overhead was a fixed
(void*).sizeof bits per block. Now, each pool has a bit
array that
contains one bit for every possible aligned pointer. The
overhead
is always 1 bit for every (void*).sizeof bytes no matter
how large
or small the block is.
Am I correct in thinking that this is still single threaded
stop the world?
Yes, but parallelization of the mark phase is fairly trivial,
and something we should probably look into.
Funny coincidence, I've just read an interview from Narihiro
Nakamura who is working on parallel marking in Ruby:
http://rubysource.com/narihiro-nakamura-rubys-gc-innovator/
BR,
renoX
