Re: [TPD] First patch
[Redirected to xemacs-beta]
On Mon, Apr 05, 1999 at 09:30:52AM -0700, Kyle Jones wrote:
Didier Verna writes:
> Kyle Jones <kyle_jones(a)wonderworks.com> writes:
>
> > I was hoping we could add big changes like the new dumper with
> > #ifdefs so the dumper could be paritally implemented and broken
> > and normal testing/debugging could continue. This doesn't look
> > like the diretion you're heading. I hope it's not too late to
> > change your mind.
>
> I don't know how much work it would involve to #ifdef the new dumper
> code, but in general, for really big changes like this (and that are supposed
> to replace former stuff), how about opening a new CVS branch with a special
> tag[1]? It avoids the problems of making the new code coexist with the old
> one, and postpone the integration process until merge time.
Someone has to maintain both trees, and I seem to remember that
being a serious deterrent to forking the tree. I think it is a
good idea nonetheless, assuming we have maintainers for both
trees.
That's the main interest of prcs. You can merge the modifications of
the main tree easily, while with cvs....
Note that I don't advocate prcs yet, I know we can't use it.
Olivier, could you outline how your dumper is going to work? I
remember doubting that it was actually portable, but we argued a
long time ago and I don't trust my memory.
I think you're refering to Ben's way.
Next patch will add the ability to move lrecords around in memory. I
see two main ways to do that, I'm still thinking about them (content
description vs. moving method). I'll probably add packing to the
current gc in order to test the system.
The gc modifications should be ifdef-able. The data or code added to
lrecords won't, but it won't be used if the gc is ifdef'ed out.
The dumping is quite similar to yours:
- gather everything that has to be dumped
- sort between readonly/writeable
- create a file with all the data in it (using the moving code)
Mine is a binary file, yours C source.
Reloading is done by:
- mmap the file if you can, else malloc and read()
- fix the adresses if needed (using the moving code too)
- hook up in the global variables
Your linked-in C code avoid the two first points, but, I think, has
other limitations, mostly by requiring a C compiler. I'd like to see,
in the future, partial dumps done for some packages (aka, fast package
loader ?) even for people using binary releases. Tradeoffs.
Also, there will be the possibility to change the base address in the
dump file so that fixing the addresses isn't needed. The idea being
that there is no real reason why the address returned by mmap() should
change between different invocations of xemacs.
Note that modern VMs use sharing and copy-on-write on mmap'ed files.
OG.