[Sbcl-devel] Core relocation (Was: WIN32 patch v.2)

[Juho S. <js...@ik...>]

<da...@li...> wrote:
> If the problem does not occur often, solving it is probably not worth
> the maintenance hassle.  If, on the other hand, it occurs very often,
> users will have to live with the cost of a larger startup time (say,
> about the time for a full GC to relocate dynamic space; about 100ms for
> a 35 MB core for me).
> 
> So are those mysterious relocatable cores everyone wants really worth it?

I think the increased robustness would definitely be worth it, as the
extra startup cost only occurs in cases that would've normally failed
completely.

> Perhaps a technical proposal helps:
> 
> I have a patch to relocate dynamic space at startup time if it cannot be
> mapped to its default location.  I have not really used this patch yet,
> but it starts up and passes the tests[*].

Cool, the approach seems sound. One style nit, validate.c shouldn't be
using mmap directly. Maybe:

   * Remove the MAP_FIXED flags also from the non-Linux implementations of
     os_validate
   * Move the "addr != actual" check in the linux os_validate to the
     callers that pass non-zero addrs
   * Use os_validate instead of the raw mmap in validate.c

And of course saving a core from relocated images needs to work. 

But other than the above, this looks committable. (It would be nice to
make the cheneygc dynamic spaces movable too, but it's orthogonal to
this patch, and at least from my point of view not a showstopper).

> This does not help with a heap that is too fragmented to map a block of
> DYNAMIC_SPACE_SIZE. An easy workaround could be to try smaller chunks
> until mapping succeeds, as suggested by foom on #lisp, although a highly
> fragmented heap would still be problematic then, as it could drastically
> reduce the available heap size.  (More clever schemes for a fragmented
> dynamic space could probably be invented but would have to involve
> changes to the page table that might not be popular, I think.)

Fragmentation as such seems like a non-problem in practice. But trying
smaller chunks would be pretty cool for environments with aggressive
memory limits.

> The patch makes no attempt at relocation of the other spaces.

That's fine, IMO.

-- 
Juho Snellman