[HarfBuzz] [Feature Request] Custom allocator support
Jamie Dale
jamiedale88+harfbuzz at gmail.com
Mon Oct 12 09:59:35 PDT 2015
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>
wrote:
> Just tested this and it worked fine. Thanks :)
>
> On 3 October 2015 at 13:20, Behdad Esfahbod <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>> 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+harfbuzz at gmail.com <mailto:
>> jamiedale88%2Bharfbuzz 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>
>> > > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>> > >
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20151012/37b8a1c4/attachment.html>
More information about the HarfBuzz
mailing list