[HarfBuzz] [Feature Request] Custom allocator support
Behdad Esfahbod
behdad.esfahbod at gmail.com
Mon Oct 12 14:22:48 PDT 2015
Fixed. Thanks.
On 15-10-12 12:59 PM, Jamie Dale wrote:
> Just tested this against another test app I have (not mine, a demo app that's
> written in C) and it failed to link as it was looking for the C++
> named-mangled versions of those externed functions. They should probably be
> declared with extern "C" around them so that they can be defined by C
> applications.
>
> In hindsight I should have mentioned this before, however I'd always assumed
> HarfBuzz was a C library due to the way its API is designed, but the templates
> in the OT font code proves otherwise :)
>
> -Jamie.
>
> On 5 October 2015 at 19:58, Jamie Dale <jamiedale88+harfbuzz at gmail.com
> <mailto:jamiedale88+harfbuzz at gmail.com>> wrote:
>
> Just tested this and it worked fine. Thanks :)
>
> On 3 October 2015 at 13:20, Behdad Esfahbod <behdad.esfahbod at gmail.com
> <mailto:behdad.esfahbod at gmail.com>> wrote:
>
> On 15-10-02 10:00 PM, Jamie Dale wrote:
> > 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?
>
> Define it to the name of your external function. I don't want to fix
> a name
> in HarfBuzz itself. Updated patch to add externs:
>
> diff --git a/src/hb-private.hh b/src/hb-private.hh
> index 07550cb..826e41a 100644
> --- a/src/hb-private.hh
> +++ b/src/hb-private.hh
> @@ -54,6 +54,23 @@
> #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)
> +extern void* hb_malloc_impl(size_t size);
> +extern void* hb_calloc_impl(size_t nmemb, size_t size);
> +extern void* hb_realloc_impl(void *, size_t size);
> +extern void hb_free_impl(void *ptr);
> +#define malloc hb_malloc_impl
> +#define calloc hb_calloc_impl
> +#define realloc hb_realloc_impl
> +#define free hb_free_impl
> +#endif
> +
>
> I'll go ahead and commit this. Let me know if it doesn't work.
>
> > 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 <mailto:behdad.esfahbod at gmail.com>
> > <mailto:behdad.esfahbod at gmail.com
> <mailto: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%2Bharfbuzz at gmail.com>
> <mailto:jamiedale88%2Bharfbuzz at gmail.com
> <mailto:jamiedale88%252Bharfbuzz at gmail.com>>
> > > <mailto:jamiedale88+harfbuzz at gmail.com
> <mailto:jamiedale88%2Bharfbuzz at gmail.com>
> <mailto:jamiedale88%2Bharfbuzz at gmail.com
> <mailto:jamiedale88%252Bharfbuzz 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
> <mailto:HarfBuzz at lists.freedesktop.org>
> <mailto:HarfBuzz at lists.freedesktop.org
> <mailto:HarfBuzz at lists.freedesktop.org>>
> > > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
> > >
> >
> >
>
>
>
More information about the HarfBuzz
mailing list