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, 88 insertions, 0 deletions

diff --git a/src/memory.h b/src/memory.h
new file mode 100644
index 0000000..e1596ea
--- /dev/null
+++ b/src/memory.h
@@ -0,0 +1,88 @@
+/*
+ * Copyright (C) 2012-2016 Robin Haberkorn
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __MEMORY_H
+#define __MEMORY_H
+
+#include <glib.h>
+
+/**
+ * Default memory limit (500mb, assuming SI units).
+ */
+#define MEMORY_LIMIT_DEFAULT (500*1000*1000)
+
+namespace SciTECO {
+
+/**
+ * Common base class for all objects in SciTECO.
+ * This is currently only used to provide custom new/delete
+ * replacements in order to support unified allocation via
+ * Glib (g_malloc and g_slice) and as a memory usage
+ * counting fallback.
+ *
+ * This approach has certain drawbacks, e.g. you cannot
+ * derive from Object privately; nor is it possible to
+ * influence allocations in other libraries or even of
+ * scalars (e.g. new char[5]).
+ *
+ * C++14 (supported by GCC >= 5) has global sized delete
+ * replacements which would be effective in the entire application
+ * but we're still using the base-class approach since
+ * we must support the older compilers anyway.
+ */
+class Object {
+public:
+	static void *operator new(size_t size) noexcept;
+	static inline void *
+	operator new[](size_t size) noexcept
+	{
+		return operator new(size);
+	}
+	static inline void *
+	operator new(size_t size, void *ptr) noexcept
+	{
+		return ptr;
+	}
+
+	static void operator delete(void *ptr, size_t size) noexcept;
+	static inline void
+	operator delete[](void *ptr, size_t size) noexcept
+	{
+		operator delete(ptr, size);
+	}
+};
+
+extern class MemoryLimit : public Object {
+public:
+	/**
+	 * Undo stack memory limit in bytes.
+	 * 0 means no limiting.
+	 */
+	gsize limit;
+
+	MemoryLimit() : limit(MEMORY_LIMIT_DEFAULT) {}
+
+	gsize get_usage(void);
+
+	void set_limit(gsize new_limit = 0);
+
+	void check(void);
+} memlimit;
+
+} /* namespace SciTECO */
+
+#endif