Re: quick malloc guard patch

2005-06-06 Thread Ted Unangst
On Wed, 25 May 2005, Ted Unangst wrote:

 it is part of G.  we will wait to see what effects it has.

and now it's option P.  for some apps, it interfered with normal operation 
too much.

-- 
And that's why he won't get my vote.



Re: quick malloc guard patch

2005-05-25 Thread Janne Johansson
Jonathan Thornburg wrote:
 when malloc gets a request with a size equal to the size of a pointer, we
 can allocate a whole page, and return a pointer 4 bytes from the end. 
 the
 four bytes allocated are useable, but don't touch the fifth or any later
 ones.  (8 bytes on 64bit archs).
 
 Is the plan to make this the default behavior, or just to add it as
 another option selectable by /etc/malloc.conf?

This would make all 4/8-byte mallocs take up one page(4k) each if I
understand this correctly.

That's fine for debugging, but probably too expensive for normal usage.

-- 
Janne Johansson
Sektionen fvr IT  Media, Stockholms Universitet
Frescati Hagvdg 10
106 91 STOCKHOLM
http://www.it.su.se



Re: quick malloc guard patch

2005-05-25 Thread Hannah Schroeter
Hello!

On Wed, May 25, 2005 at 03:17:59PM +0200, Janne Johansson wrote:
[...]

This would make all 4/8-byte mallocs take up one page(4k) each if I
understand this correctly.

That's fine for debugging, but probably too expensive for normal usage.

I tend to agree. While most applications will allocate 4/8 byte values
either as local variables or as part of something bigger, you can't
exclude cases where generic code could hit that case in masses.

Take for example a list of variable-length lists of integers:

int **list;
int *sizes;

sizes = (int *) malloc(lines * sizeof(int));
list = (int **) malloc(lines * sizeof(int*));

/* error checking, of course */

for (i = 0; i  lines; ++ i) {
sizes[i] = choose_size(i);
list[i] = (int *) malloc(sizes[i] * sizeof(int));
choose_values(list[i], sizes[i]);
}

Now if the sizes returned by choose_size are in a distribution with
an average of a few (say 4), but with a big variation, a size of 1 might
occur often enough, i.e. you might waste *much* memory and time (mmap of
single pages might well hit the kernel much).

That's why I tend to agree, very cool idea for debugging (like it seems
to be now, with the flag G), but not a low enough overhead for full
production use (*un*like things like propolice etc.).

Kind regards,

Hannah.