On Monday, 17 de October de 2011 11:44:10 André Pönitz wrote: > > In fact, that's not a bad idea: storing an extra header past the end of > > the data. It wouldn't affect the alignment constraints. > > Why "past"? Don't we typically get memory allocated at 16*n+8, and would > like to use 16*m (with m = n+1 perhaps) instead? Adjusting it would leave > us with a "natural" gap of 8 bytes in front of the "main" data, 4 of which > could be used for the hash. > > Actually, with 4 more left, couldn't even the "alloc" field could go there? > It's rarely accessed, and would take some pressure off the main structure.
You know, every time I look at a heap pointer value in 32-bit Linux in a
debugger, it ends in hex 8 . That is, like you said, the pointer value is a
16*n+8.
However, the histogram when I profiled the string data shows that pointers of
16*n also happen and are quite common. I'd say that over a large sample, they
are probably close to half of the heap pointers.
Given a 16+8 byte headers, we could position the 8 bytes either before or
after the data so that we align the data.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
