From 39cfc5731695c46a337606da9bc86a659dbad5b3 Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Sun, 5 Mar 2017 18:15:05 +0100 Subject: replaced Linux-specific mallinfo()-based memory limiting with a more portable and faster hack * Works by "hooking" into malloc() and friends and counting the usable heap object sizes with malloc_usable_size(). Thus, it has no memory-overhead. * Will work at least on Linux and (Free)BSD. Other UNIXoid systems may work as well - this is tested by ./configure. * Usually faster than even the fallback implementation since the memory limit is hit earlier. * A similar approach could be tried on Windows (TODO). * A proper memory-limiting counting all malloc()s in the system can make a huge difference as this test case shows: sciteco -e '<@EU[X^E\a]"^E\a"%a>' It will allocate gigabytes before hitting the 500MB memory limit... * Fixed the UNIX-function checks on BSDs. --- TODO | 25 +++++-------------------- 1 file changed, 5 insertions(+), 20 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 2488da9..9230fed 100644 --- a/TODO +++ b/TODO @@ -249,26 +249,11 @@ Features: Macros may retrieve the code and string of the last error. Optimizations: - * The Linux-specific memory limiting using mallinfo() is - very slow (50% to 150% slower than the fallback implementation - measured in batch mode). - The fallback implementation does not come with much of a - runtime penalty. - Still I've found no faster way of measuring the process heap. - A soft resource limit would be ideal but unfortunately, - it lets malloc() return NULL and we're not in control of all - the mallocs, so glib could abort before we have a chance to - react on it. - Since the slow-down affects interactive mode as well, disabling - limiting in batch mode is merely a workaround. - Perhaps Linux should simply use the fallback limiting as well - (or support this via a configure option). - On Windows (2000), the overhead is approx. the same. - * Another Linux/glibc-specific workaround may be to hook into - all malloc(), realloc() and free() calls and count the - "usable" size of each heap object, thus avoiding mallinfo(). - Malloc hooks are deprecated, but the symbols are weak and - can be overwritten. + * 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. + This must be benchmarked. * Add G_UNLIKELY to all error throws. * Instead of using RTTI to implement the immediate editing command behaviours in Cmdline::process_edit_cmd() depending on the current -- cgit v1.2.3