[Top][All Lists]

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

Re: Aligned blocks management: obsolete?

From: Dmitry Antipov
Subject: Re: Aligned blocks management: obsolete?
Date: Thu, 21 Jun 2012 08:27:14 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 06/20/2012 09:10 PM, Eli Zaretskii wrote:

From: Dmitry Antipov <address@hidden>
CC: Paul Eggert <address@hidden>, Eli Zaretskii <address@hidden>,
  Emacs development discussions <address@hidden>

For example, attached code checks whether memalign tends to create holes
while allocating (1024 - 8) blocks aligned at 1024-bytes boundary; optimal
pad (BLOCK_PADDING in current code) may be detected with the similar way.

Is it possible to incorporate such tests into Emacs, and write some
Lisp to execute the tests and report the results?

Such a test can be embedded into configure script.  Moreover, I believe
it might be applicable outside of Emacs; IMHO, it would be nice to have
such a test as a part of gnulib.

I'm asking because it's hard to use this test as-is on MS-Windows,
since all of the related functions used by the Windows build are
reimplemented by Emacs sources, they are not in any system library,
and so linking a stand-alone test program is not easy.

Previous discussions shows my incompetence in Windows-related areas of
Emacs development, so I have no ideas.

P.S. If memory fragmentation is what you worry about, then doesn't
ralloc.c free us from this, on platforms that use it?

I don't know how ralloc.c works.  In general, I believe moving/compacting
GC is the only way to reduce fragmentation; since current design makes it
impossible to move/compact Lisp objects, any underlying allocator can't
really help to reduce fragmentation.

As for the lisp_align_{malloc,free}, this cleanup was designed just because
I have some experimental mmap stuff and want to make some simplifications
before introducing even more complexities :-).


Attachment: lisp_align_malloc_cleanup.patch
Description: Text document

reply via email to

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