[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: block-based vector allocator

From: Stefan Monnier
Subject: Re: Proposal: block-based vector allocator
Date: Mon, 21 May 2012 16:12:45 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

>>> +#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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]