From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 20 Nov 2015 22:44:51 +0000 Message-ID: References: <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564DF0F6.5060501@cs.ucla.edu> <564E5375.3050006@cs.ucla.edu> <564E6045.6030907@cs.ucla.edu> <564E620A.5020709@cs.ucla.edu> <564F8AD6.4090400@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114423382dd375052500a054 X-Trace: ger.gmane.org 1448059527 32564 80.91.229.3 (20 Nov 2015 22:45:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 22:45:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 23:45:27 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZzuQh-0006SU-4K for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 23:45:19 +0100 Original-Received: from localhost ([::1]:50215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzuQg-00018F-Cz for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 17:45:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzuQS-000165-Qp for emacs-devel@gnu.org; Fri, 20 Nov 2015 17:45:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzuQR-0006tE-PO for emacs-devel@gnu.org; Fri, 20 Nov 2015 17:45:04 -0500 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:33066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzuQP-0006so-QO; Fri, 20 Nov 2015 17:45:02 -0500 Original-Received: by wmec201 with SMTP id c201so91411785wme.0; Fri, 20 Nov 2015 14:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=bvPngQpgqCE/kP8XWKAjB9R5Y8KUp1raHBF3BoBkdc4=; b=RyHQtgJE5bNAHtOnp0DIAXX8GUpPJdlOV+VqvhDfLDqGm2XA+TbjL9M2RKiqcNr7vN yy2L2AczpGHlN/IvpSv7e90qzbLC0IridmD0yutZUN6FGPlIrGq1Px0kSfduFP0Vi/rQ 0u37iJtF9YaCamo5ZwDCLcHzM89MA10h0g8HimT8YsV+oHZCJezNm9uOooo4ulxbp0Et 88PodxMqWNvgdE4mV7KrSUTDxGhbgGdcpyOekxZcXaT0uHkY3u2nvUu7z0U5/8Ar83ms VXD139Y3RCIhCIU4bopifG063MYTz+3tykUBKkf/XqJWIlUKcy+I2JCK8V0ttdWXqGV8 oEsQ== X-Received: by 10.28.134.199 with SMTP id i190mr4835087wmd.33.1448059501136; Fri, 20 Nov 2015 14:45:01 -0800 (PST) In-Reply-To: <564F8AD6.4090400@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194908 Archived-At: --001a114423382dd375052500a054 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Fr., 20. Nov. 2015 um 22:04 Uhr: > Philipp Stephani wrote: > > Modules will > > typically be used to wrap existing C or C++ libraries or make heavy use > of > > such libraries, and those libraries won't use an Emacs-specific > allocator. > > It's quite likely that wrappers will need to allocate memory to marshal > data > back and forth between C and Elisp. If I wanted to build a module to use > GMP, > for example, I'd want to use GMP's low-level primitives that don't do > memory > management, and have the wrapper manage memory itself. > > I suppose some wrappers won't need to manage memory at all, but I'd say > most > libraries need memory, and the overall system will benefit from having a > single > memory manager rather than having each library manage its own memory > independently. > That sounds reasonable, and since there is no other way for modules to use Emacs's allocator it would make sense to add it to the module interface (the env object), as long as modules remain free to pick any allocator. > > Have you used the Emacs memory profiler? > I think once, but not regularly. Still sounds like a useful thing to have. --001a114423382dd375052500a054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Fr., 20. Nov. 2015 um 22:04=C2=A0Uhr:
Philipp Stephani wrote:
> Modules will
> typically be used to wrap existing C or C++ libraries or make heavy us= e of
> such libraries, and those libraries won't use an Emacs-specific al= locator.

It's quite likely that wrappers will need to allocate memory to marshal= data
back and forth between C and Elisp.=C2=A0 If I wanted to build a module to = use GMP,
for example, I'd want to use GMP's low-level primitives that don= 9;t do memory
management, and have the wrapper manage memory itself.

I suppose some wrappers won't need to manage memory at all, but I'd= say most
libraries need memory, and the overall system will benefit from having a si= ngle
memory manager rather than having each library manage its own memory indepe= ndently.

That sounds reasonable, and si= nce there is no other way for modules to use Emacs's allocator it would= make sense to add it to the module interface (the env object), as long as = modules remain free to pick any allocator.
=C2=A0

Have you used the Emacs memory profiler?

I think once, but not regularly. Still sounds like a useful thing to have= .
=C2=A0
--001a114423382dd375052500a054--