Sheez, you step out of the room for a moment....

It seems there's been some confusion (around here, anyway) about the malloc
that the X server is using.

When last I paid attention, the server's "internal malloc" was little more than
a set of function shells over the usual library calls.  Now they really have an
internal malloc worthy of the name, with interesting features and some
interesting comments (all in xc/programs/Xserver/os/xalloc.c).

This bears on our discussion because I haven't been running an X server that
uses that internal malloc.  I built one to use the GNU malloc option with a
named malloc library.  This practice dates back a few years.

The irony here is that the newer internal malloc's realloc ALWAYS does an
allocate-copy-deallocate cycle, so it would never have encountered the partial
deallocation inefficiencies of the Mach vm.  Now I have to run an X server
that uses the internal malloc, and see how that goes.

Meanwhile, a curious monkey wrench from my own efforts to patch the Mach vm so
it will clean up those partial deallocations and free the pages.  My first go
at this seems to work with everything EXCEPT the X server:  that baby hangs
after changing the video mode, with a dead keyboard (naturally, so I can't get
into ddb to find out what happened).  Other programs seem to show a modest
improvement in memory consumption, without complaint.

I assume this must be a subtle bug in what I did -- otherwise, by what logic
could the X server hang just on THAT change in kernel behavior?!? -- but I'm
amazed that it would only trip up the X server, and nothing else.  I've thrown
some known problem reallocators at it, with nary a stutter.

Oh well, so it goes....


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 30-Apr-98
Time: 10:24:54

This message was sent by XFMail
----------------------------------