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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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 08:59:11 -0800

[Message part 1 (text/plain, inline)]

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.

> 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.

> 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?

> That's too drastic, IMO. We will eventually do that, in time, but 
> doing that in the same commit that makes the function obsolete is too 
> soon. 

OK, less-drastic patch attached.

[0001-Make-memory-limit-obsolete.patch (application/x-patch, attachment)]

Previous Next

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