|
|
Subscribe / Log in / New account

Improving portability advice

Improving portability advice

Posted Jun 10, 2019 13:17 UTC (Mon) by bcopeland (subscriber, #51750)
In reply to: Improving portability advice by itvirta
Parent article: Detecting and handling split locks

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.


to post comments

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


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds