From: | "Maurice Gittens" <mgittens(at)gits(dot)nl> |
---|---|
To: | "David Gould" <dg(at)illustra(dot)com>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <scrappy(at)hub(dot)org>, <mgittens(at)david(dot)gits(dot)nl>, <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] patch for memory overrun on Linux(i386) |
Date: | 1998-03-22 09:42:30 |
Message-ID: | 004001bd5576$d5cb1500$fcf3b2c2@caleb..gits.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Maurice Gittens | 1998-03-22 09:45:32 | Re: [HACKERS] patch for memory overrun on Linux(i386) |
Previous Message | David Gould | 1998-03-22 09:00:56 | Re: [HACKERS] psql nested queries with 2000+ records |