Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Feb 1996 11:08:20 -0700
From:      Nate Williams <nate@sri.MT.net>
To:        "Andrew V. Stesin" <stesin@elvisti.kiev.ua>
Cc:        stable@freebsd.org
Subject:   Re: What I'd like to see brought to -stable
Message-ID:  <199602011808.LAA20364@rocky.sri.MT.net>
In-Reply-To: <199602011252.OAA11080@office.elvisti.kiev.ua>
References:  <199602011050.CAA01444@Root.COM> <199602011252.OAA11080@office.elvisti.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Andrew V. Stesin writes:
[ Wishlist for -stable ]
> # >2.  "phk malloc" by Paul Henning Kampf. It's one of the best performance
> # >    improvements I've seen, why recompile approx. entire world after
> # >    dropping it into an installed system? And, taken from -current,
> # >    it works without a glitch -- only _times_ faster :)
> # 
> #   No, sorry, this won't be in the release. The main problem is that phk's
> # malloc does a better job recycling memory and this exposes bugs in
> # applications.
...
> 	New malloc() is of _much_ less risk to use than, for example,
> 	brand new UNIX pipes. The same with userland utils.

Huh?  Very few applications use pipes, but *lots* (most) of the
applications use malloc, so using simple math the chances of a serious bug
occuring because of phk-malloc will be greater than bugs found with
pipes.

Now, given the amount of time that phk-malloc has had to get beat on in
-current it's unlikely that real obvious bugs still exist, but there is
still a chance.

> 	And who forbids you, in case things are going wrong in
> 	-stable snapshots (they're experimental, anyway),
> 	replace phk malloc back with todays one?

That goes against the grain of -stable.  That's what -current is for. :)



Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602011808.LAA20364>