unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Aligned blocks management: obsolete?
Date: Wed, 20 Jun 2012 20:06:44 +0300	[thread overview]
Message-ID: <83wr31diaj.fsf@gnu.org> (raw)
In-Reply-To: <4FE171EC.8000503@yandex.ru>

> Date: Wed, 20 Jun 2012 10:47:08 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Emacs development discussions <emacs-devel@gnu.org>
> 
> This code tries to utilize system malloc features and falls back to legacy
> aligned blocks management code if system malloc implementation is unknown,
> broken, or lacks aligned allocation routines.
> 
> It will be great if someone can help to test this on Windows, OSX, old *BSD
> and other non-GNU/Linux systems

What exactly would you like us to test, beyond the fact that the
patched sources compile?

Anyway, I don't understand the motivation for the changes you've done
relative to the previous version.  In particular:

> +#if ! HAVE_POSIX_MEMALIGN && ! HAVE_WORKING_MEMALIGN && ! _MSC_VER

Why only _MSC_VER is being tested here?  This will only catch the MSVC
build of Emacs, but will miss the MinGW (GCC-based) Windows build and
the MS-DOS build.  If you wanted to catch all of them, you should test
DOS_NT instead.

> +#ifdef HAVE_POSIX_MEMALIGN
> +  if (posix_memalign (&val, BLOCK_ALIGN, nbytes))
> +    val = NULL;
> +#elif HAVE_WORKING_MEMALIGN
> +  val = memalign (BLOCK_ALIGN, nbytes);
> +#elif _MSC_VER
> +  /* Yes, the order of arguments is correct.  */
> +  val = _aligned_malloc (nbytes, BLOCK_ALIGN);
> +#else
> +  val = internal_align_alloc (nbytes);
> +#endif

The _MSC_VER part is not right, IMO.  The Windows build, whether MinGW
or MSVC, uses gmalloc.c for its malloc implementation, with sbrk
(implemented in w32heap.c) that calls directly into the VM allocation
APIs, and is thus similar to mmap-based memory allocation on Posix
hosts, in that it doesn't suffer from fragmentation.

By contrast, _aligned_malloc is most probably a very thin wrapper
around MS runtime implementation of malloc (MS documentation says
"_aligned_malloc is based on malloc"), and we certainly don't want to
use that malloc in Emacs, because it will be definitely prone to
severe fragmentation problems.

So, unless I'm missing something, the MS-Windows build (and also the
MS-DOS one) should defined HAVE_POSIX_MEMALIGN and use its
implementation provided by gmalloc.c.  Unless, that is, you think that
gmalloc's implementation of posix_memalign is not good enough, in
which case we will be much better off improving it than switching to
MS's malloc.



  parent reply	other threads:[~2012-06-20 17:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12  8:11 Aligned blocks management: obsolete? Dmitry Antipov
2011-12-12 13:13 ` Eli Zaretskii
2011-12-12 14:07   ` Dmitry Antipov
2011-12-12 18:11     ` Eli Zaretskii
2011-12-12 18:27     ` Paul Eggert
2012-06-19 16:51       ` Dmitry Antipov
2012-06-19 17:13         ` Eli Zaretskii
2012-06-19 21:34         ` Stefan Monnier
2012-06-20  6:47           ` Dmitry Antipov
2012-06-20 12:48             ` Stefan Monnier
2012-06-20 13:54               ` Dmitry Antipov
2012-06-20 15:41                 ` Stefan Monnier
2012-06-20 17:10                 ` Eli Zaretskii
2012-06-21  4:27                   ` Dmitry Antipov
2012-06-21 16:29                     ` Eli Zaretskii
2012-07-04  8:39                       ` Old topic(s) again [was: Re: Aligned blocks management: obsolete?] Dmitry Antipov
2012-07-04 13:11                         ` Stefan Monnier
2012-06-21 21:34                     ` Aligned blocks management: obsolete? Richard Stallman
2012-06-20 17:06             ` Eli Zaretskii [this message]
2012-06-21  3:30               ` Dmitry Antipov
2012-06-21 16:23                 ` Eli Zaretskii
2012-06-20 17:59             ` Wolfgang Jenkner
2012-06-21  3:12               ` Dmitry Antipov
2012-06-20  6:53         ` Paul Eggert
2011-12-12 18:38 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wr31diaj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dmantipov@yandex.ru \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).