Re: [HACKERS] patch for memory overrun on Linux(i386)
От | Maurice Gittens |
---|---|
Тема | Re: [HACKERS] patch for memory overrun on Linux(i386) |
Дата | |
Msg-id | 004001bd5576$d5cb1500$fcf3b2c2@caleb..gits.nl обсуждение исходный текст |
Ответы |
Re: [HACKERS] patch for memory overrun on Linux(i386)
|
Список | pgsql-hackers |
> >Of course on x86 there is no special requirement any type to be aligned at all. >Double do not need to be 8 byte aligned. Ints do not need to be on an even >address etc. So malloc can return a pointer to any address it wants on an x86 >and still conform to the restriction. Yes and I think it returns 4 byte aligned objects for performance reasons. (This is more efficient than storing double/int on 1/2 byte boundaries.) > >On a Sparc or an Alpha, objects must to be aligned to the sizeof the type. >So shorts are 2 byte aligned, ints 4 byte, and doubles 8 byte. Since malloc >has no idea what you are allocating it has to return an 8 byte aligned pointer. > >But all this is a bit of a red herring. The original bug if I recall was >caused by the caller assuming that the return from palloc was 8 byte aligned. >Since the caller "knew" that the pointer was 8 byte aligned it then went on >to do some "fancy" pointer arithmetic to arrive at an offset. This is what >is broken, not the Linux malloc(). Yes, I think so too. > >That said, I have a plan in mind to get a nice performance boost for palloc(). >As a side effect, I will guarantee 8 byte alignment of pointers returned >from palloc(). > Does this imply that more memory will be used that strictly necesary under linux? With regards from Maurice.
В списке pgsql-hackers по дате отправления: