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, 2 insertions, 3 deletions

diff --git a/TODO b/TODO
index 9230fed..ff1568a 100644
--- a/TODO
+++ b/TODO
@@ -250,9 +250,8 @@ Features:
 
 Optimizations:
  * The Windows-specific memory limiting using GetProcessMemoryInfo()
-   is very slow. Perhaps a similar approach to the generic UNIX
-   malloc() hooking can be implemented and memory_usage counted
-   with _msize() from MSVCRT.
+   is very slow. Perhaps malloc() hooking can be implemented there,
+   using _msize() to measure the memory required by individual chunks.
    This must be benchmarked.
  * Add G_UNLIKELY to all error throws.
  * Instead of using RTTI to implement the immediate editing command