GNU bug report logs - #24892
{s,}brk removed from FreeBSD 11.x and later, arm64 architecture

Previous Next

Full log

Message #80 received at 24892 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24892 <at> debbugs.gnu.org
Subject: Re: bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64
 architecture
Date: Thu, 10 Nov 2016 19:24:31 +0200

> Cc: 24892 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 10 Nov 2016 08:59:11 -0800
> 
> On 11/10/2016 08:13 AM, Eli Zaretskii wrote:
> > how can zero be a useful approximation of the memory footprint of a 
> > running process?
> 
> It's not, but memory-limit is not about memory footprint.

It is, in a way, although it only reports part of that footprint.

> > What does memory-limit return on your system?
> 
> 47668, representing about 47 MiB. In contrast, (alist-get 'vsize 
> (process-attributes (emacs-pid))) returns 807344, representing about 788 
> MiB. So 0 is numerically closer to the "correct" answer.

"Numerically closer" doesn't mean "useful".  Depending on what the
user wants, either result could be useful, but zero isn't.

> > I think we should have a function that does this in, say, simple.el, 
> > under a name such as emacs-memory-size, and point to that in the 
> > obsolescence note.
> 
> Something like that could be done in a later patch. However, the notion 
> "memory size" is vague and prone to misinterpretation, so any later 
> patch should be done carefully. And I'm leery of defining a function 
> that nobody is asking for - if nobody has cared for many years that 
> memory-limit has been returning bogus values, then why do we need a 
> function at all?

It only returned bogus results on some platforms.

FWIW, I'm frequently interested in the Emacs memory footprint, for
various reasons, so having a function in Emacs would be handy.

> OK, less-drastic patch attached.

Thanks, LGTM for master.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.