[HarfBuzz] [Feature Request] Custom allocator support

[Jamie Dale]

That's similar to what I originally had, so I'm fine with something like
that. My only question is, what would hb_malloc_impl, hb_calloc_impl,
hb_realloc_impl, and hb_free_impl be defined to in your example?

I went with the extern function approach so I could inject my own allocator
functions into HarfBuzz at link time, rather than have to include any of
our code into HarfBuzz at compile time (since any local code changes we
make have to be re-applied against new versions).

For your reference, this was my original implementation:

/* Override the allocation functions 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 malloc _hb_malloc
#define calloc _hb_calloc
#define realloc _hb_realloc
#define free _hb_free
#endif

Failure to define those functions in something that linked to HarfBuzz
would produce an unresolved external symbol error at link time.

-Jamie.

On 2 October 2015 at 08:08, Behdad Esfahbod <behdad.esfahbod at gmail.com>
wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20151002/f511d2a4/attachment.html>