[HarfBuzz] [Feature Request] Custom allocator support

Behdad Esfahbod behdad.esfahbod at gmail.com
Fri Oct 2 00:08:57 PDT 2015


Hi Jamie,

I'm opposed to runtime custom allocators, but am fine with something like what
you suggest.  However, that has two down sides:

  1. It touches a lot of callsites,

  2. I have to add macros to make sure stock malloc etc are not used by mistake.

If doing 2., I might as well just define them to their custom behavior.  Ie,
would this patch work for you:

diff --git a/src/hb-private.hh b/src/hb-private.hh
index 07550cb..167c067 100644
--- a/src/hb-private.hh
+++ b/src/hb-private.hh
@@ -54,6 +54,19 @@
 #include <stdarg.h>


+/* Compile-time custom allocator support. */
+
+#if defined(hb_malloc_impl) \
+ && defined(hb_calloc_impl) \
+ && defined(hb_realloc_impl) \
+ && defined(hb_free_impl)
+#define malloc hb_malloc_impl
+#define calloc hb_calloc_impl
+#define realloc hb_realloc_impl
+#define free hb_free_impl
+#endif
+
+
 /* Compiler attributes */




On 15-09-30 03:49 PM, Jamie Dale wrote:
> Since there was no movement here I went ahead and hacked in our allocator by
> redefining malloc, calloc, realloc, and free to point to extern'd functions
> that I define in our application. This yielded some performance benefits for
> us, so I'm hoping that a more standard HarfBuzz solution might appear at some
> point :)
> 
> If you're not keen on the idea of allowing the allocator to be swapped out at
> runtime, would you at least allow it to be extern'd at compile time? I'm not
> familiar with HarfBuzz coding standards, but I'd propose adding something like
> a HAVE_EXTERNAL_ALLOCATOR define to control this, and then define your own
> allocator functions that you'd use in place of malloc, etc.
> 
> Basically, something like this (I currently have this code in hb-private.hh):
> 
> /* Define our allocation functions. These may be provided by an 
>  * external source when HAVE_EXTERNAL_ALLOCATOR is defined. */
> #ifdef HAVE_EXTERNAL_ALLOCATOR
> extern void* _hb_malloc(size_t);
> extern void* _hb_calloc(size_t, size_t);
> extern void* _hb_realloc(void*, size_t);
> extern void _hb_free(void*);
> #define hb_malloc _hb_malloc
> #define hb_calloc _hb_calloc
> #define hb_realloc _hb_realloc
> #define hb_free _hb_free
> #else
> #define hb_malloc malloc
> #define hb_calloc calloc
> #define hb_realloc realloc
> #define hb_free free
> #endif
> 
> You'd then replace calls to malloc, calloc, realloc, and free from within
> HarfBuzz to use hb_malloc, hb_calloc, hb_realloc, and hb_free.
> 
> This is basically the code I already have, except I
> redefined malloc, calloc, realloc, and free rather than create the
> hb_*variants, as I didn't want to change too much HarfBuzz code.
> 
> Thoughts?
> 
> On 31 August 2015 at 22:17, Jamie Dale <jamiedale88+harfbuzz at gmail.com
> <mailto:jamiedale88+harfbuzz at gmail.com>> wrote:
> 
>     Hey,
> 
>     I'm not sure if this is correct place to post/discuss feature requests...
>     hopefully it is.
> 
>     Our project makes use of a custom memory allocator, and we like to ensure
>     that our third-party libraries are using this where possible, as our
>     allocator can offer significantly better performance, and can also allow
>     us better memory profiling and debugging support.
> 
>     A look through the HarfBuzz source code would suggest that it doesn't
>     currently support custom memory allocators, and instead just directly
>     calls the standard malloc/free/etc functions. I was wondering if you'd
>     ever considered (or would consider) adding a way to override this behaviour?
> 
>     In my case, I'd just need a single global override to be set before my
>     first call to any other HarfBuzz code... basically something like
>     the FT_Memory struct from FreeType:
>     http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Memory
> 
>     Thanks,
>     Jamie.
> 
> 
> 
> 
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> 


More information about the HarfBuzz mailing list