On Sun, Oct 10, 1999 at 02:46:04PM +0200, Jan Vroonhof wrote:
- How have you addressed the problem of the mark phase of GC writing
to the file?
That's what I'm working on right now: using an external hash table for
marking instead of an internal markbit.
- 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.
Very. You just have to rebuild the layout you want in memory in the
file you write. Actually I loved your suggestion, and I'm in the
process of removing all the flags from the lrecord header. The
*readonly flags are almost unused, the *dumped flags a mistake I'm
correcting.
- 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.
There is no fundamental reason that would make that impossible. The
only problem is that a fully running XEmacs includes a bunch of things
we definitively don't want to try to dump, like devices or buffers.
We would somehow have to avoid them, which is not easy if they have
symbols pointing to them.
OG.