<div dir="ltr">Hello Experts,<div><br></div><div>We have a static allocator based on shared memory in use today (with predefined memory segment sizes), but there is just too much of internal fragmentation and our memory requirement in keep on increasing (we have close to 60-70GB in use today - with practically needing 20-30GB). We tried several option to live with the current allocator but it is extremely hard to have a configuration which can work with varying traffic patterns. </div><div><br></div><div>To address the problem, I am considering to use a dynamic allocator based on shared memory. The basic idea is to have the allocator work across process boundaries and to have the things stored in shared memory to survive process crashes or restarts. </div><div><br></div><div>After analyzing many allocators, I am thinking to port jemalloc to shared memory. I have done a very high level look into jemalloc with a simple prototype. In my prototype I am pre-allocating a big shared memory chunk using a fixed address (which is aligned to chunk size boundary of 4MB). With this I think jemalloc would be able to manage memory across processes.</div><div><br></div><div>I have few queries in general,</div><div><br></div><div>1. Currently I am using a fixed address aligned to 4MB boundary. Is there a way for me to avoid using a fixed address? </div><div><br></div><div>2. Is it safe to use a fixed high memory address for my application?</div><div><br></div><div>3. Is it possible to make jemalloc work with page alignment for chunks instead of chunk alignment? If yes, could you suggest any way for this - without huge rework in jemalloc? My primary idea is to get out of fixed address (AFAIK, Linux guarantees shared memory segments to be page aligned)</div><div><br></div><div>4. I see that tsd cleanup do not work (including arena cleanup) when process exits. Is there a way to ensure this? Or do I need to introduce some garbage collection mechanism on top?</div><div><br></div><div>Thanks and Regards,<br></div><div>Abi</div></div>