Date: Tue, 14 Mar 2006 23:18:57 +0900 From: SANETO Takanori <sanewo@ba2.so-net.ne.jp> To: Jason Evans <jasone@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: malloc options incompatibility between phkmalloc and jemalloc Message-ID: <4416D0D1.8010101@ba2.so-net.ne.jp> In-Reply-To: <4415DB8F.6060409@FreeBSD.org> References: <200601161150.k0GBoamk010563@locutus.newmillennium.net.au> <91B40C65-A11B-427E-B352-8B6EF8A55864@freebsd.org> <43CECA2C.6030400@ba2.so-net.ne.jp> <6A234191-C4DA-4E1B-BB4D-1F3F8043DDA9@freebsd.org> <4413C5D8.70208@ba2.so-net.ne.jp> <4415DB8F.6060409@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4416D0D1.8010101>