Improving portability advice

Posted Jun 9, 2019 11:53 UTC (Sun) by mirabilos (subscriber, #84359)
In reply to: Improving portability advice by marcH
Parent article: Detecting and handling split locks

Oh, so ESR wrote a detailled article about it. I only knew from OpenBSD commits and figuring out the rest myself.

Yes! I’ve significantly reduced the in-memory size of several structures (which are then used in arrays, which pads them to powers of 2 at the end too, so going down from 36 to 32 actually reduces from 64 to 32) in some codebasēs.

Improving portability advice

Posted Jun 9, 2019 18:44 UTC (Sun) by itvirta (guest, #49997) [Link] (3 responses)

What exactly pads your structures to powers of two in arrays?

Improving portability advice

Posted Jun 10, 2019 13:17 UTC (Mon) by bcopeland (subscriber, #51750) [Link] (2 responses)

If the arrays are dynamically allocated, slab allocator (for example) might do this. I once looked at a case that was allocating a bunch of individual pointers that all got rounded up from 8 to 32 bytes, meaning 75% of each allocation was unused. It makes sense that the allocators work that way, but if you don't know that and do this sort of thing hundreds of times, and especially if the memory being allocated happens to be something like 2**n + small_amount, you can accidentally waste a lot of memory.

Improving portability advice

Posted Jun 11, 2019 13:26 UTC (Tue) by k8to (guest, #15413) [Link]

The typical userland allocators on Solaris & Windows also behave this way. It's not very surprising.

On Linux my memory is a bit muddied between the default glibc allocator, tcmalloc, jemalloc etc. so I'm less confident, but I would expect the same.

Improving portability advice

Posted Jun 11, 2019 15:02 UTC (Tue) by fotoba (subscriber, #61150) [Link]

If pointers will be huge or far
not near or not specified
https://www.geeksforgeeks.org/what-are-near-far-and-huge-...

This problem will not happend as I read well waht happend