[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] mem_node shrink #2
From: |
Dmitry Antipov |
Subject: |
Re: [patch] mem_node shrink #2 |
Date: |
Fri, 30 Nov 2007 17:09:38 +0300 |
User-agent: |
Thunderbird 2.0.0.9 (X11/20071115) |
Stefan Monnier wrote:
+/* Otherwise, every region which is passed to mem_insert is never larger
+ than 256M, so it's size fits into BITS_PER_INT - 4 bits wide bit field. */
Is that true? Why is it the case?
On 64bit systems we can have buffers larger than 256MB.
If buffer text is xmalloc'ed, (re)allocated region is not mem_insert'ed unless
GC_MALLOC_CHECK is defined.
If you run (buffer-substring (point-min) (point-max)) when current buffer's size
is 300M (on 64-bit system), the storage for resulting string is allocated with
MEM_TYPE_NON_LISP and isn't mem_insert'ed too.
But yes, it still has problems - on 64-bit system, (make-vector 50000000 nil)
wants ~380M of MEM_TYPE_VECTOR, which isn't fit. So my stuff introduces vector
size limits - (32M - 3) items on 64-bit and (64M - 3) on 32-bit. It looks
acceptable for me, but I'm not sure about others.
Is there any other code which may wants to allocate >256M ?
Dmitry