Re: Portable dumper ideas
On Wed, Feb 16, 2000 at 03:42:25AM -0800, Kyle Jones wrote:
Martin Buchholz writes:
> Wouldn't we get a tremendous performance boost by having the
> lrecord_implementations_table indices be constant? We would lose a
> level of indirection on every FOOP, because it would not have to
> examine lrecord_implementations_table itself.
Yes, this is a great idea. I think the reason the changeover to
minimal tagbits was a wash speedwise was because of increased
time spent type checking. We got rid of the pointer masking and
unmasking, but almost all the type checks got more expensive.
We need a game plan.
One one hand, we have the possibility of implementing the paginated
allocator. Type testing will become "*(blah **)(ptr & MASK) ==
constant)"[1]. This is mostly equivalent (one instruction difference)
to the "*(byte *)(ptr) == constant" you'd like to have. A good thing
with such a paginated allocator is that fixed block types will go, and
lrecord-lists will probably become useless. Bad thing is that it will
be a huge change in the portable dumper. Also, I'm not sure how much
the overhead will be, but I'm afraid it may overweight the space gain
we would have. Also, we will have to kill all the flags.
On the other hand, we can decide not to implement the allocator. I
can hack a way to get the data sharing back which will cost only
~40Kbytes of memory at run time without, I hope, changing the speed of
marking/unmarking in a noticeable manner. We can also add a small
program to lib-src that will look at all the
DEFINE_*_LRECORD_*_IMPLEMENTATION and generate a big enum in a file
out of them.
Also, what would you think of:
- killing basic_p and free
- splitting the symbol_value_magic type in multiple types, separating
in particular forwarders to C from the rest
OG.
[1] MASK=~((1<<PAGESIZE)-1), blah = lrecord_implementation *, constant =
&lrecord_<type>