Kenichi Okuyama <okuyama(a)trl.ibm.co.jp> writes in xemacs-beta(a)xemacs.org:
>>>>> "SJ" == Simon Josefsson
<jas(a)pdc.kth.se> writes:
>> Build 21.0 betas with `--with-minimal-tagbits'. It raises the 28-bit
>> limit to 31-bit.
There's more to it than that. It also moves the tagbit from the
topmost bit to the lower most bit. This will work fine so long as
malloc() returns memory that is aligned to at least 32 bit boundaries.
SJ> We're getting somewhere. :-)
I would like to say that "Even 31 bit is not enough".
As all of you in this ML know, emacs allocates cons-cells and other
"tiny" resources by chunk of 1k using malloc. But if we can make
this size to 4k, and use "mmap()" system call, on some machine, it
will increase Virtual Memory usage, which will lessen the swap IO
and make entire system works faster.
We do this already. With the old GNU malloc in XEmacs, the mmapping
version of the relocating allocator can be used. The new GNU
malloc (Doug Lea malloc) in Linux libc5 and GNU libc uses mmapping for
allocation under certain conditions. Note that FSF Emacs 20.2 can use
the Doug Lea malloc, but it unconditionally turns off usage of mmap.
I haven't checked 20.3 to see if they fixed that.
(all we need to do is use PHKmalloc instead of GNU-malloc and change
constant from 1024 to 4096)
What is PHKmalloc? If it's portable and faster, I have no problem
replacing the old GNU malloc with it, or adding it as an additional
option.
But, for AIX, mmap() will map the new page to address higher then
0x80000000, which means we need 32nd bit. I'm pretty sure that even
on some other OS have same kind of limitation.
Yup. DL malloc does that too. Fortunately Kyle has already fixed the
XEmacs internals so that the tagbits are on the low side so all of the
high bits are usable in pointer addresses.
...
So this is what I want to say:
"We need entire addressing space. If you have any Idea on
putting new information into address bit field, please don't.
We need entire addressing space for addressing."
We have the entire addressing space with 32 bit alignment. We don't
have more than 31 bits available for integers.