Re: MALLOC/FREE macro useage.
On Sun, 2 Sep 2001, Alfred Perlstein wrote: * John Polstra [EMAIL PROTECTED] [010902 20:23] wrote: In article [EMAIL PROTECTED], Gersh [EMAIL PROTECTED] wrote: sys/malloc.h says that the macro versions of MALLOC/FREE are deprecated however they are used all over the place. I belive that they are cluttering and dont really have a purpose. Does anybody else agree? Yes (I wrote the line that says they are deprecated). If I were to make up a patch for current removing all of them would anybody care enough to commit it (Or care enough to not have it commited) No. Please don't. It would just create a bunch of new gratuitous differences against the other BSDs. At least in old code. The reason for the macro is that when the size paramter is a constant there's an evil trick that makes selecting the malloc bucket really cheap. That's not the reason. The size parameter is not constant since MALLOC() just calls malloc(). I wouldn't call the big conditional statement in BUCKETINDX() an evil trick. But perhaps it should be replaced by fls(). A builtin fls() could handle constants just as well. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MALLOC/FREE macro useage.
* Bruce Evans [EMAIL PROTECTED] [010903 03:47] wrote: On Sun, 2 Sep 2001, Alfred Perlstein wrote: The reason for the macro is that when the size paramter is a constant there's an evil trick that makes selecting the malloc bucket really cheap. That's not the reason. The size parameter is not constant since MALLOC() just calls malloc(). I wouldn't call the big conditional statement in BUCKETINDX() an evil trick. But perhaps it should be replaced by fls(). A builtin fls() could handle constants just as well. Well it was the original intent, in fact it was done such that when a constant was used and the bucket wasn't empty the code would expand to just a handful of instructions. This is mentioned in Design and Implementation. As far as BUCKETINDX(), i almost thought that instead of doing power of two buckets, we could use mod-32, this would do nifty things like when we just barely go over 128 bytes for something we don't waste nearly double our allocation. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' 'Java developer, like special Olympics, right?' - Bill Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MALLOC/FREE macro useage.
In article [EMAIL PROTECTED], Gersh [EMAIL PROTECTED] wrote: sys/malloc.h says that the macro versions of MALLOC/FREE are deprecated however they are used all over the place. I belive that they are cluttering and dont really have a purpose. Does anybody else agree? If I were to make up a patch for current removing all of them would anybody care enough to commit it (Or care enough to not have it commited) Please don't. It would just create a bunch of new gratuitous differences against the other BSDs. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MALLOC/FREE macro useage.
* John Polstra [EMAIL PROTECTED] [010902 20:23] wrote: In article [EMAIL PROTECTED], Gersh [EMAIL PROTECTED] wrote: sys/malloc.h says that the macro versions of MALLOC/FREE are deprecated however they are used all over the place. I belive that they are cluttering and dont really have a purpose. Does anybody else agree? If I were to make up a patch for current removing all of them would anybody care enough to commit it (Or care enough to not have it commited) Please don't. It would just create a bunch of new gratuitous differences against the other BSDs. The reason for the macro is that when the size paramter is a constant there's an evil trick that makes selecting the malloc bucket really cheap. Please don't remove it. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
