[sqlite] static malloc_zone_t* _sqliteZone_
Ok, that's what I finally convinced myself, too. Thanks for the confirmation. - Andy On Wed, Mar 4, 2015 at 4:24 PM, Scott Perry wrote: > Good eye, thanks for reporting this. > > Pointers on the stack or in static storage are pointer-aligned by default on > all of Apple's platforms. > > On Mar 3, 2015, at 7:27 PM, Andy Rahn wrote: >> >> Hi SQLite users; >> >> I have a question about _sqliteZone_ in mem1.c. I notice that the >> address of this static variable is used in a call to >> OSAtomicCompareAndSwapPtrBarrier on MacOS and iOS. That system call >> is declared in OSAtomic.h, which includes a note about the pointer >> alignment of its arguments: >> >>> * WARNING: all addresses passed to these functions must be "naturally >>> aligned", >>> * i.e. * int32_t pointers must be 32-bit aligned (low 2 bits >>> of >>> * address are zeroes), and int64_t pointers must be 64-bit >>> aligned >>> * (low 3 bits of address are zeroes.) >> >> I wonder, therefore, if it might be prudent to declare _sqliteZone_ >> with the alignment attribute, so that the compiler is sure to put it >> at a 32 / 64 bit aligned address space? e .g. >> >> static __attribute__((aligned(8))) malloc_zone_t* _sqliteZone_; >> >> and also, because this local variable is used in that same function: >> >> __attribute__((aligned(8))) malloc_zone_t* newzone = >> malloc_create_zone(4096, 0); >> >> I see that attribute is used one other place, so this may be an >> important nuance. On a 32-bit architecture, it would be safe to use >> aligned(4) instead of aligned(8) but I'm not sure anyone will care >> about the (possible) 4-byte savings. >> >> - Andy >> ___ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] static malloc_zone_t* _sqliteZone_
Good eye, thanks for reporting this. Pointers on the stack or in static storage are pointer-aligned by default on all of Apple's platforms. On Mar 3, 2015, at 7:27 PM, Andy Rahn wrote: > > Hi SQLite users; > > I have a question about _sqliteZone_ in mem1.c. I notice that the > address of this static variable is used in a call to > OSAtomicCompareAndSwapPtrBarrier on MacOS and iOS. That system call > is declared in OSAtomic.h, which includes a note about the pointer > alignment of its arguments: > >> * WARNING: all addresses passed to these functions must be "naturally >> aligned", >> * i.e. * int32_t pointers must be 32-bit aligned (low 2 bits of >> * address are zeroes), and int64_t pointers must be 64-bit >> aligned >> * (low 3 bits of address are zeroes.) > > I wonder, therefore, if it might be prudent to declare _sqliteZone_ > with the alignment attribute, so that the compiler is sure to put it > at a 32 / 64 bit aligned address space? e .g. > > static __attribute__((aligned(8))) malloc_zone_t* _sqliteZone_; > > and also, because this local variable is used in that same function: > > __attribute__((aligned(8))) malloc_zone_t* newzone = > malloc_create_zone(4096, 0); > > I see that attribute is used one other place, so this may be an > important nuance. On a 32-bit architecture, it would be safe to use > aligned(4) instead of aligned(8) but I'm not sure anyone will care > about the (possible) 4-byte savings. > > - Andy > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] static malloc_zone_t* _sqliteZone_
Hi SQLite users; I have a question about _sqliteZone_ in mem1.c. I notice that the address of this static variable is used in a call to OSAtomicCompareAndSwapPtrBarrier on MacOS and iOS. That system call is declared in OSAtomic.h, which includes a note about the pointer alignment of its arguments: > * WARNING: all addresses passed to these functions must be "naturally > aligned", > * i.e. * int32_t pointers must be 32-bit aligned (low 2 bits of > * address are zeroes), and int64_t pointers must be 64-bit > aligned > * (low 3 bits of address are zeroes.) I wonder, therefore, if it might be prudent to declare _sqliteZone_ with the alignment attribute, so that the compiler is sure to put it at a 32 / 64 bit aligned address space? e .g. static __attribute__((aligned(8))) malloc_zone_t* _sqliteZone_; and also, because this local variable is used in that same function: __attribute__((aligned(8))) malloc_zone_t* newzone = malloc_create_zone(4096, 0); I see that attribute is used one other place, so this may be an important nuance. On a 32-bit architecture, it would be safe to use aligned(4) instead of aligned(8) but I'm not sure anyone will care about the (possible) 4-byte savings. - Andy
