[Top][All Lists]

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

Re: Proposal: block-based vector allocator

From: Dmitry Antipov
Subject: Re: Proposal: block-based vector allocator
Date: Fri, 01 Jun 2012 13:06:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 06/01/2012 09:44 AM, Paul Eggert wrote:

On non-USE_LSB_TAG system, roundup_size is orthogonal to pointer
values (roundup_size can't be less than sizeof (Lisp_Object), of course).

Ah, OK, then we can make roundup_size be the equivalent of
COMMON_MULTIPLE (sizeof (Lisp_Object), defined USE_LSB_TAG ? 8 : 1).

For example, 32-bit system (non-wide-int, i.e. sizeof (Lisp_Object) == 4)
without USE_LSB_TAG is expected to work with roundup_size = 4, but I can't
test this and have no ideas why it's worth trying at all.

It would waste less memory due to internal fragmentation, which
would be a win.  I don't see the downside -- perhaps you could

I expect very negligible win here. But I'll try to reconfigure with
--enable-use-lisp-union-type and see what happens.

BTW, is this configuration usable? When I'm trying to configure with
this option, I still get USE_LSB_TAG - but the comment in lisp.h says
they're incompatible. I suppose we shouldn't enforce USE_LSB_TAG
if USE_LISP_UNION_TYPE is defined, i.e.:

=== modified file 'src/lisp.h'
--- src/lisp.h  2012-05-30 19:23:37 +0000
+++ src/lisp.h  2012-06-01 08:58:16 +0000
@@ -201,9 +201,10 @@
 # endif

-/* Let's USE_LSB_TAG on systems where we know malloc returns mult-of-8.  */
+/* If USE_LISP_UNION_TYPE is not explicitly enabled, let's USE_LSB_TAG
+   on systems where we know malloc returns mult-of-8.  */
 #if (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \
-     || defined DARWIN_OS || defined __sun)
+     || defined DARWIN_OS || defined __sun) && !defined USE_LISP_UNION_TYPE
 /* We also need to be able to specify mult-of-8 alignment on static vars.  */
 # if defined DECL_ALIGN
 /* On hosts where pointers-as-ints do not exceed VAL_MAX,


reply via email to

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