Re: Proposal: block-based vector allocator

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> +#define VECTOR_BLOCK_SIZE (4096)
[...]
>>> +/* One pointer is malloc overhead, others are BUMP and NEXT fields of struct
>>> +   vector_block.  Rounding helps to maintain alignment constraints.  */
>>> +#define VECTOR_BLOCK_BYTES \
>>> +  (VECTOR_BLOCK_SIZE - roundup (3 * sizeof (void *), roundup_size))
>> Why do we care about malloc overhead?
> IIUC, if/when we will have mmap()ed Lisp_Objects someday, this should help
> malloc() to do direct mmap()/munmap() of page-size vector blocks.

There are several conditions here, some of them might never
actually happen.  So I'd rather not worry about it for now.

We can even define VECTOR_BLOCK_BYTES to some arbitrary constant and not
worry about VECTOR_BLOCK_SIZE at all, then.

>> BTW, if needed we could add a special case so there is only 1 vector of
>> size 0 and (make-vector 0 ?) always returns that same vector (so it
>> doesn't have to come from a vector_block).
> Should we allocate it from pure space?

Yes, we could do that.

> As for the roundup() check, it looks like GNU/Linux and *BSD systems
> both has it in sys/param.h, but (Open)Solaris uses sys/sysmacros.h.
> So I'm trying to check for the most common case and then fall back
> to simple default.

Since it's a constant we can choose, we can choose that constant to be
one that makes for efficient code.  So I think we don't need to use some
predefined macro but can code up our own, custom-designed for our
specific needs, without worry about where various systems define
`roundup'.


        Stefan