Re: read-only GC spaces

On Sun, 2008-11-09 at 12:00 +0600, Ivan Shmakov wrote:

> 	I wonder, what it'd take to implement read-only GC spaces,
> 	either a read-only space for two-space GC, or arbitrary number
> 	of read-only spaces for Bibop?

If the objects within such spaces ought to be collected at some time,
then I would say that it's a big bunch of work. That's because the
collector overwrites a part of every object during it's collection.
It would be much easier if the read-only objects are "large"; such
objects are never moved by bibop (and thus never written to), but they
take at least 4kB per object.

Regarding the image and Bibop, things might be easier. If it's a
bibop-format image, then the image is currently loaded in three chunks
(one for small/large/weak objects each). The memory needed for them is
specially allocated by the GC, and then filled by the dumper at once.
This process could be somehow "reversed", with the dumper passing the
already-loaded "mmap memory" to the GC, which then "integrates" it.
Bibop already integrates this space directly into the last generation,
which is optionally never(*) collected (the option is turned on, and
named "S48_USE_STATIC_SPACE" in the sources).
      (*) as far as I remember.
I can't remember if objects are ever added to this "static space", but
it shouldn't be that much work around that.

But another obstacle comes to my mind: Is every single object in the
image actually never mutated? If some are, then you also need a way to
know about that, plus a new image format and a new dumper.

> 	The implementation of read-only GC spaces would allow for mmap
> 	() system call to be used to memory-less map scheme48.image (or,
> 	possibly, even arbitrary data arrays), thus drastically reducing
> 	the per-process memory consumption for Scheme48 (from, I
> 	believe, about 5 MiB on amd64 currently, to probably less than 1
> 	MiB.)
> 
> 	Also, it would allow for the whole Scheme48 run-time system to
> 	be pre-compiled into the image, thus saving both the time
> 	(otherwise needed to byte-compile the code) and memory space
> 	when loading extensions, thus making Scheme48 behavior
> 	comparable the the one of the languages (implementations) making
> 	use of shared libraries, such as C or Chicken Scheme, with
> 	respect to the memory consumption.
> 
> 	I guess that since Bibop already supports multiple spaces, it'd
> 	be easier to implement read-only spaces support for it than for
> 	the two-space GC?  Is there any description of its internals, or
> 	should I start with the source code?

There is something like a description; but only in German. Mike Sperber
has it.

So I guess you would've to take your chance on the sources ;-) If you
look for "image", be aware that some things only apply to the older
"portable dumper", which can read twospace-images into Bibop (and vica
versa).

Regarding the twospace-GC, I would mainly see the performance as a
concern. As it would have to distinguish between objects in a read-only
space and the normal ones during collection (which it currently does not
have to). And then either not collect the former at all, or do a special
way of collection.

> 
> 	Should the mmap () support be then implemented somewhere deeply
> 	within the VM?
> 

-- 
David