search

minad / tlsf

Two-Level Segregated Fit Memory Allocator
https://github.com/minad/tlsf
Other
11 stars 3 forks source link

Is this project under maintenance? #2

Closed shiwawaxp closed 5 years ago

shiwawaxp commented 5 years ago

The forking project is great! I'm wondering whether this project under maintenance and what's the quality status? i did not see update recently. What's the next relesse?

minad commented 5 years ago

It is not really maintained, since I am not using it right now. I had hoped that some changes could go upstream. However the upstream project seems to be unmaintained.

There are other forks which seem to have quite a few patches. Maybe all of those could be merged? Maybe @mattconte could appoint a maintainer?

Ping other forks @alnsn @akritid @wloop @andylamp @pasiopou

minad commented 5 years ago

See also https://github.com/mattconte/tlsf/issues/4

andylamp commented 5 years ago

@minad I have no issue with appointing a (or a group of) maintainer(s) and I think it's the right thing to do. We have quite a few patches but these currently cannot be pushed to the upstream project.

minad commented 5 years ago

@andylamp Let's continue the discussion upstream in https://github.com/mattconte/tlsf/issues/4

minad commented 4 years ago

@shiwawaxp @andylamp In case you are still interested - it turned out that I am using this allocator again for a project. So it is back to a maintained state. I changed the api such that it does not use pools anymore but a single linearly growing memory area (brk style). This is simpler and more appropriate for my usecase. I hope things will stay more or less as is from now on.

andylamp commented 4 years ago

@minad that's great to hear; actually, we did quite a lot of testing and internally rewrote parts of it to make it compatible with 64-bit addressing that are now public on another repo. We also wrote testing and benchmarking suites - would you like a pull request with these features or something along these lines?

minad commented 4 years ago

@andylamp Cool! In my repo there are tests and benchmarks from the repository https://github.com/jserv/tlsf-bsd by @jserv. If we could add more tests etc, that would be great! I will definitely accept PRs!

As now the implementation should support allocations up to 128G on 64 bit platforms. Changing the fl and sl bitmaps to use size_t or uint64_t leads to a blowup of the tlsf control data structure, so I would rather avoid doing that.

andylamp commented 4 years ago

that's great to hear - I'll see what I can do as my time is quite limited these days but it's encouraging that you accept PR's; this type of allocators are quite good in certain use-cases, esp. when allocation latency is paramount.

minad commented 4 years ago

I am curious - what are you using the allocator for? I am using it in a freestanding environment (something along the lines of webassembly/unikernels) and for me the main advantages is the simplicity/compactness and the good behaviour overall, constant time etc. This is quite impressive for such a small allocator of only 500 loc. However tlsf is certainly not the fastest allocator. In multithreaded scenarios it is a no-go and even in single threaded scenarios there are faster allocators. In my case this does not matter too much since I am using a slab allocator on top for small object sizes.