Re: TPD, here we go again
Olivier Galibert <galibert(a)pobox.com> writes:
3. Remaining issues
The build process will have to start a post-dump xemacs, ask it the
loading address (which will, hopefully, be always the same between
different xemacs invocations) and relocate the file to the new
address. This way the object relocation phase will not have to be
done, which means no writes in the objects and that, because of the
use of mmap, the dumped data will be shared between all the xemacs
running on the computer.
Some questions
- How have you addressed the problem of the mark phase of GC writing
to the file?
- How flexible is this with regard to the in memory representation of
objects. In particular using a typed pool allocator as I suggested a
while back to reduce the memory overhead of using l[c]records for
everything. I still think 50% memory overhead is a lot.
- Would it be possible for an xemacs to 're-pdump' itself? In particular
it would be nice to be able to re-pdump XEmacs after every package
upgrade and thus avoid the package scanning altogether. For this be
feasible the pdumping needs to be robust and be possible from the
distributed binary.
Jan