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, 18 deletions

diff --git a/src/qregisters.h b/src/qregisters.h
index bcea2f2..cb50b6f 100644
--- a/src/qregisters.h
+++ b/src/qregisters.h
@@ -28,6 +28,7 @@
 #include <Scintilla.h>
 
 #include "sciteco.h"
+#include "memory.h"
 #include "error.h"
 #include "interface.h"
 #include "ioview.h"
@@ -47,7 +48,7 @@ namespace QRegisters {
  * Classes
  */
 
-class QRegisterData {
+class QRegisterData : public Object {
 protected:
 	tecoInt integer;
 
@@ -241,12 +242,6 @@ class QRegisterClipboard : public QRegister {
 		}
 
 		void run(void);
-
-		gsize
-		get_size(void) const
-		{
-			return sizeof(*this) + strlen(name) + str_len;
-		}
 	};
 
 	/**
@@ -289,8 +284,8 @@ public:
 	void undo_exchange_string(QRegisterData &reg);
 };
 
-class QRegisterTable : private RBTreeString {
-	class UndoTokenRemove : public UndoTokenWithSize<UndoTokenRemove> {
+class QRegisterTable : private RBTreeString, public Object {
+	class UndoTokenRemove : public UndoToken {
 		QRegisterTable *table;
 		QRegister *reg;
 
@@ -392,7 +387,7 @@ public:
 	}
 };
 
-class QRegisterStack {
+class QRegisterStack : public Object {
 	class Entry : public QRegisterData {
 	public:
 		SLIST_ENTRY(Entry) entries;
@@ -415,16 +410,9 @@ class QRegisterStack {
 		}
 
 		void run(void);
-
-		gsize
-		get_size(void) const
-		{
-			return entry ? sizeof(*this) + sizeof(*entry)
-			             : sizeof(*this);
-		}
 	};
 
-	class UndoTokenPop : public UndoTokenWithSize<UndoTokenPop> {
+	class UndoTokenPop : public UndoToken {
 		QRegisterStack *stack;
 
 	public: