roll back to the old mallinfo() implementation of memory limiting on Linux and added a FreeBSD/jemalloc-specific implementation

 * largely reverts 39cfc573, but leaves in minor and documentation
   changes.
 * further experimentation of memory limiting using malloc() wrapping
   has shown additional problems, like dlsym() calling malloc-functions,
   further reducing the implementation to glibc-specific means.
   This means there had been no implementation for FreeBSD and checks
   would have to rely on undocumented internal implementation details
   of different libcs, which is not a good thing.
   * Other problems have been identified, like having to wrap calloc(),
     guarding against underruns and multi-thread safety had been identified
     but could be worked around.
 * A technique by calculating the memory usage as sbrk(0) - &end
   has been shown to be effective enough, at least on glibc.
   However even on glibc it has shortcomings since malloc() will
   somtimes use mmap() for allocations and the technique
   relies on implementation details of the libc.
   Furthermore another malloc_trim(0) had to be added to the error
   recovery in interactive mode, since glibc does not adjust the program break
   automatically (to avoid syscalls I presume).
 * On FreeBSD/jemalloc, the sbrk(0) method totally fails because jemalloc
   exclusively allocates via mmap() -> that solution was discarded as well.
 * Since all evaluated techniques turn out to be highly platform
   specific, I reverted to the simple and stable platform-specific
   mallinfo() API on Linux.
 * On FreeBSD/jemalloc, it's possible to use mallctl("stats.allocated")
   for the same purpose - so it works there, too now.
   It's slower than the other techniques, though.
 * A lengthy discussion has been added to memory.cpp, so that we
   do not repeat the previous mistakes.

1 files changed, 3 insertions, 3 deletions

diff --git a/src/cmdline.cpp b/src/cmdline.cpp
index f1bbe83..ffe44d6 100644
--- a/src/cmdline.cpp
+++ b/src/cmdline.cpp
@@ -264,9 +264,9 @@ Cmdline::keypress(gchar key)
 		 * Glibc/Linux-only optimization: Undo stacks can grow very
 		 * large - sometimes large enough to make the system
 		 * swap and become unresponsive.
-		 * This will often reduce the amount of memory previously
-		 * freed that's still allocated to the program immediately
-		 * when the command-line is terminated:
+		 * This shrink the program break after lots of memory has
+		 * been freed, reducing the virtual memory size and aiding
+		 * in recovering from swapping issues.
 		 */
 		malloc_trim(0);
 #endif