Re: read-only GC spaces

>>>>> David Frese <[email protected]> writes:

 >> 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.

	Since we'd have these GC spaces ``for free'' (with respect to
	the memory consumption), they could probably be ommitted from
	regular GC.

	IIUC, that's what the generational GC are all about -- to have
	different GC intervals for different spaces.  Here, the interval
	would be set to infinity.

 > 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.

	Yes, I saw something like this in the source.

 > This process could be somehow "reversed", with the dumper passing the
 > already-loaded "mmap memory" to the GC, which then "integrates" it.

	That's probably the way to do 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.

	It seems useful.  Thanks for the pointer!

 > But another obstacle comes to my mind: Is every single object in the
 > image actually never mutated?

	I guess that the cells bound to the global variables in
	non-``static'' environments are mutable, and obviously they
	could be dumped to the image.

 > If some are, then you also need a way to know about that, plus a new
 > image format and a new dumper.

	This could probably worked around (at least temporarily), as
	mmaped regions could actually be changed, while keeping the
	changes private to the process (i. e., with the conventional
	copy on write semantics.)

	But yes, it makes sense to keep the mutable and immutable
	objects separated within the image.

[...]

 >> 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.

	While my German skills are next to non-existent, why not to make
	it available?  Perhaps, I, or someone else, be able to get some
	useful bits of it.

[...]