apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject RE: [PATCH] apr_rmm.c
Date Fri, 18 Apr 2003 14:55:20 GMT
--On Friday, April 18, 2003 7:49 AM -0700 "MATHIHALLI,MADHUSUDAN 
(HP-Cupertino,ex1)" <madhum@hp.com> wrote:

>> How about using APR_ALIGN_DEFAULT instead of computing grain?
>
>
> Sure - anything to make sure that the allocation is always a multiple of 8
> would do :)..
>
> Question : Is 8 sufficient ?. What if there is a "long double" in some data
> structure - where the allocation would change again.. The apr_rmm headers
> are probably okay - the compiler always allocates 16  bytes.
>
> OR, is it better to have the value '8' in APR_ALIGN_DEFAULT to be determined
> during the configure phase ?.

It's not necessarily about the long double (or the largest element in a 
structure) - AIUI, it's that the base pointer needs to be aligned by 8 rather 
than 4.  I don't believe it has anything to do with the internal structure. 
Since all of the pool allocated memory is currently aligned by 8, I've got to 
imagine that's sufficient.  If it weren't, then you'd see a SIGBUS on all 
memory operations.  If we had to grow the alignment for a specific platform, 
we'd do it in APR_ALIGN_DEFAULT.  So, that seems to me to be the right 
strategy for apr_rmm.

Perhaps someone else can shed some light on this...  -- justin

Mime
View raw message