Re: malloc options incompatibility between phkmalloc and jemalloc

From: SANETO Takanori <sanewo_at_ba2.so-net.ne.jp>
Date: Tue, 14 Mar 2006 23:18:57 +0900
Thanks for your explanation.

Although I can finally agree that current situation won't be changed, in
most cases (at leat for my case), just adding two more place (new
environment variable and new symlink) for malloc options and ignoring
old fashioned option characters will solve the problem, I guess.
(i.e., use of _malloc_options might be rare)

Isn't it the case?

Jason Evans wrote:
> SANETO Takanori wrote:
>> I don't think this is serious problem, but it's annoying.
>>
>> When I put 'k' in /etc/malloc.conf, some commands (cvsup and
>> vmware-checkvm) show warning about unknown character. These commands
>> seem to have phkmalloc implementation linked statically.
>>
>> On the other hand, when I put '>' in /etc/malloc.conf, many commands
>> will show warnings.
>>
>> For second case, isn't it reasonable for jemalloc to just ignore
>> phkmalloc specific characters?
>> For first case, how about introducing new option source (i.e.
>> /etc/jemalloc.conf, JEMALLOC_OPTIONS or something like that)?
>>
>> What do you think?
> 
> This is a sticky issue.  I'd rather leave things as they are, partly
> because I expect the "fix" would actually be quite messy.  I view malloc
> options as pretty much exclusively a devel/debug aid, rather than a
> stable API.  In order to truly fix this API, I think we'd have to go
> further than what you suggest.  The _malloc_options global variable is
> harder to deal with than MALLOC_OPTIONS or /etc/malloc.conf when trying
> to design a fix.
> 
> The problem for _malloc_options is that we can't reliably use a
> function-based API, since malloc may be called before the application
> has a chance to configure the allocator.  As such, there is no direct
> way for an app to respond to malloc option incompatibilities.
> 
> It would be possible to construct a more complex interface for malloc
> configuration that would mostly solve these issues, but I don't think
> it's worth the added complexity for a devel/debug facility.
> 
> Jason
Received on Tue Mar 14 2006 - 13:19:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC