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

Previous Next

Full log

Message #65 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 18:13:24 +0200

> Cc: 24892 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 9 Nov 2016 17:47:19 -0800
> 
> On 11/09/2016 07:49 AM, Eli Zaretskii wrote:
> > we could lift the implementation from
> > system_process_attributes, we report there the process memory size.
> 
> That number is not that relevant to the intent of memory-limit, and on 
> my platform (Fedora 24 x86-64) returning 0 is a better approximation. 

That's strange: how can zero be a useful approximation of the memory
footprint of a running process?  What does memory-limit return on your
system?

> That being said, we can add some help along those lines, in the attached 
> patch, slightly modified from the original to suggest (alist-get 'vsize 
> (process-attributes (emacs-pid))) for users who prefer the virtual 
> memory size.

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

>  DEFUN ("memory-limit", Fmemory_limit, Smemory_limit, 0, 0, 0,
> -       doc: /* Return the address of the last byte Emacs has allocated, divided by 1024.
> -This may be helpful in debugging Emacs's memory usage.
> -We divide the value by 1024 to make sure it fits in a Lisp integer.  */)
> +       doc: /* Return zero.  */)
>    (void)
>  {
> -  Lisp_Object end;
> -
> -#if defined HAVE_NS || !HAVE_SBRK
> -  /* Avoid warning.  sbrk has no relation to memory allocated anyway.  */
> -  XSETINT (end, 0);
> -#else
> -  XSETINT (end, (intptr_t) (char *) sbrk (0) / 1024);
> -#endif
> -
> -  return end;
> +  return make_number (0);
>  }

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.

Previous Next

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