fixed glib warnings about using g_mem_set_vtable() and revised memory limiting

 * we were basing the glib allocators on throwing std::bad_alloc just like
   the C++ operators. However, this always was unsafe since we were throwing
   exceptions across plain-C frames (Glib).
   Also, the memory vtable has been deprecated in Glib, resulting in
   ugly warnings.
 * Instead, we now let the C++ new/delete operators work like Glib
   by basing them on g_malloc/g_slice.
   This means they will assert and the application will terminate
   abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
   more important to have a good memory limiting mechanism.
 * Memory limiting has been completely revised.
   Instead of approximating undo stack sizes using virtual methods
   (which is unprecise and comes with a performance penalty),
   we now use a common base class SciTECO::Object to count the memory
   required by all objects allocated within SciTECO.
   This is less precise than using global replacement new/deletes
   which would allow us to control allocations in all C++ code including
   Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
   checks would be cumbersome.
   In any case, we're missing Glib allocations (esp. strings).
 * As a platform-specific extension, on Linux/glibc we use mallinfo()
   to count the exact memory usage of the process.
   On Windows, we use GetProcessMemoryInfo() -- the latter implementation
   is currently UNTESTED.
 * We use g_malloc() for new/delete operators when there is
   malloc_trim() since g_slice does not free heap chunks properly
   (probably does its own mmap()ing), rendering malloc_trim() ineffective.
   We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
   be available elsewhere) and found that it brings no significant
   performance benefit.
   On all other platforms, we use g_slice since it is assumed
   that it at least does not hurt.
   The new g_slice based allocators should be tested on MSVCRT
   since I assume that they bring a significant performance benefit
   on Windows.
 * Memory limiting does now work in batch mode as well and is still
   enabled by default.
 * The old UndoTokenWithSize CRTP hack could be removed.
   UndoStack operations should be a bit faster now.
   But on the other hand, there will be an overhead due to repeated
   memory limit checking on every processed character.

1 files changed, 6 insertions, 2 deletions

diff --git a/configure.ac b/configure.ac
index 517f4a0..42094ec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -124,9 +124,13 @@ AC_CHECK_HEADERS([bsd/sys/queue.h], [], [
 
 case $host in
 *-mingw*)
-	AC_CHECK_HEADERS([windows.h], , [
+	AC_CHECK_HEADERS([windows.h psapi.h], , [
 		AC_MSG_ERROR([Missing Windows headers!])
 	])
+
+	# Make sure we get GetProcessMemoryInfo():
+	AM_CPPFLAGS="$AM_CPPFLAGS -DPSAPI_VERSION=1"
+	LIBS="$LIBS -lpsapi"
 	;;
 esac
 
@@ -154,7 +158,7 @@ esac
 # Check for optional GNU libc features.
 # Will probably only be found on Linux.
 AC_CHECK_HEADERS([malloc.h])
-AC_CHECK_FUNCS([malloc_trim])
+AC_CHECK_FUNCS([malloc_trim mallinfo])
 
 #
 # Config options