4:40 a.m.
"J. Kean Johnston" <jkj(a)sco.com> writes:
All,
Once the module loading technology is in place and people are happier
with it, I would like to start work on ripping out major parts of XEmacs
and putting them in modules. I havem in my prototype tree, a mechanism
in place where a given source file can either be compiled in as part
of the dumped Emacs, or as a module. If module loading is availible,
the makefile is constructed in such a way that it compiles things as
modules rather than part of the dumped Emacs. This is a good thing.
It is not only possible, but preferable (I believe) to make large parts of
XEmacs modules. It will also make distribution a lot easier. I am working
on making the TTY and X11 code loadable, so that you only ever load in
those parts that you care about.
Doesn't this (demand paging?) happen on virtually every operating system
out there? (given some sort of assumption about locality in some way)
I guess that you could argue "no" because some sort of initialization
that has to occur. (could this be done lazily to get some of the same
effect?)
This gives users choices they didnt have before (eg, I think I'll
try
loading the Lucid widgets instead of the mOtif ones)
This, I buy. This would be very nice to have.
and it reduces
the
size of the in-memory footprint of Emacs considerably.
See above. Does this _really_ matter so much? The fact is that it _is_
all shared, and it _is_ demand paged, so this is sort of a possibly
shaky win. Would it _really_ be worth the work?
Soren
5:43 a.m.
New subject: What to do with modules now ...
I don't see that it is. There hasn't been any clamor for dynamic
loading of the X11 code for instance, and it would be quite a job
to implement. It's hard to believe that the bug count would
decrease as a result of this, either.
9:06 a.m.
New subject: What to do with modules now ...
At 21:43 10/01/99 -0800, Kyle Jones wrote:
I don't see that it is. There hasn't been any clamor for
dynamic
loading of the X11 code for instance, and it would be quite a job
to implement. It's hard to believe that the bug count would
decrease as a result of this, either.
I still think the biggest win would be dynamic loading of natively compiled
lisp. But that probably also requires Kyles portable undumper and we've
already agreed it might be difficult. I agree with Kyle breaking of chunks
like X is going to result in a lot of bugs.
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
11:25 a.m.
New subject: What to do with modules now ...
>>>> "Soren" == Soren Dayton
<csdayton(a)cs.uchicago.edu> writes:
Soren> See above. Does this _really_ matter so much? The fact is that it _is_
Soren> all shared, and it _is_ demand paged, so this is sort of a possibly
Soren> shaky win. Would it _really_ be worth the work?
I'll add one more comment to this discussion. Although I don't
believe keeping the size of the CODE in the executable small should
really matter on a good OS, the size of the lisp data does matter a
lot. This is because every garbage collection touches ALL the lisp
data, and so ALL the lisp data is part of the minimal working set of
the XEmacs process. But if you're only putting DEFUNs into your
modules, you're not getting much in the way of lisp data savings. One
non-obvious benefit of rewriting lisp functions in C is that they
suffer far less garbage collection overhead.
A challenge for those of you who really want to make XEmacs faster.
Write a bytecode to C compiler. It's not that hard! It's already
pretty close to assembly language. Turn every lisp defun into a
loadable module. Use the new module system for THAT.
Martin
10:32 p.m.
New subject: What to do with modules now ...
Martin Buchholz writes:
>>>>> "Soren" == Soren Dayton
<csdayton(a)cs.uchicago.edu> writes:
Soren> See above. Does this _really_ matter so much? The fact is that it _is_
Soren> all shared, and it _is_ demand paged, so this is sort of a possibly
Soren> shaky win. Would it _really_ be worth the work?
I'll add one more comment to this discussion. Although I don't
believe keeping the size of the CODE in the executable small should
really matter on a good OS, the size of the lisp data does matter a
lot. This is because every garbage collection touches ALL the lisp
data, and so ALL the lisp data is part of the minimal working set of
the XEmacs process.
Note that dumped LIsp object pages are read but not written during
GC. So they can be shared across XEmacs instances, if the dumper
puts those pages in the text segment of the binary. This happens
under BSD/OS, but apparently the switch to ELF-style binaries has
hosed this for everyone else.
11:10 p.m.
New subject: What to do with modules now ...
On Sun, Jan 17, 1999 at 02:32:16PM -0800, Kyle Jones wrote:
Note that dumped LIsp object pages are read but not written during
GC. So they can be shared across XEmacs instances, if the dumper
puts those pages in the text segment of the binary. This happens
under BSD/OS, but apparently the switch to ELF-style binaries has
hosed this for everyone else.
You mean "pure lisp", I guess. The undumping process dumps everything
lying in memory without consideration for whether it is in the
purespace or not.
Modern VMs will share the data pages in copy-on-write mode, so the
purespace is still shared no matter in which section it is.
What would you think about removing the purespace array entirely but
keeping the "pure" flag on the lrecords ? We won't have n dump
attemps anymore and it would make the portable undumper slightly
easier.
OG.
6:46 a.m.
New subject: What to do with modules now ...
Olivier Galibert writes:
What would you think about removing the purespace array entirely
but
keeping the "pure" flag on the lrecords ? We won't have n dump
attemps anymore and it would make the portable undumper slightly
easier.
Sound fine to me. That is part of my plan for the new dumper
anyway. The minimal tagbits work was done because clean pointers
were needed for the dumper. The indexed lrecord implementation
work was done because the dumper needed some per-object status
bits and some place had to be found to store them.
9:41 a.m.
New subject: What to do with modules now ...
At 20:25 17/01/99 +0900, Martin Buchholz wrote:
A challenge for those of you who really want to make XEmacs faster.
Write a bytecode to C compiler. It's not that hard! It's already
pretty close to assembly language. Turn every lisp defun into a
loadable module. Use the new module system for THAT.
Seconded (although I believe I have actually posted this idea a number of
times :)
andy
---------------------------------------------------------------------------
" .sigs are like your face - rarely seen by you and uglier than you think"
Dr Andy Piper, Technical Architect, Parallax Solutions Ltd
mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp
9252
days inactive
9259
days old
7 comments
5 participants
participants (5)
-
Andy Piper -
Kyle Jones -
Martin Buchholz -
Olivier Galibert -
Soren Dayton