From b7ff56db631be7416cf228dff89cb23d753e4ec8 Mon Sep 17 00:00:00 2001 From: Robin Haberkorn Date: Sun, 20 Nov 2016 09:00:50 +0100 Subject: 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. --- src/expressions.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'src/expressions.h') diff --git a/src/expressions.h b/src/expressions.h index cdb2d3e..50962fd 100644 --- a/src/expressions.h +++ b/src/expressions.h @@ -20,20 +20,21 @@ #include +#include "memory.h" #include "undo.h" #include "error.h" namespace SciTECO { template -class ValueStack { +class ValueStack : public Object { /* * NOTE: Since value stacks are usually singleton, * we pass them as a template parameter, saving space * in the undo token. */ template &stack> - class UndoTokenPush : public UndoTokenWithSize> { + class UndoTokenPush : public UndoToken { Type value; guint index; @@ -49,7 +50,7 @@ class ValueStack { }; template &stack> - class UndoTokenPop : public UndoTokenWithSize> { + class UndoTokenPop : public UndoToken { guint index; public: @@ -158,7 +159,7 @@ public: /** * Arithmetic expression stacks */ -extern class Expressions { +extern class Expressions : public Object { public: /** * Operator type. -- cgit v1.2.3