4 ms·
Issues I found at a glance: 1. This uses unsigned int for the chunk size, so the allocator will overflow on requests of 4GB or more despite taking a size_t. It
by pcwalton 7y ago
Issues I found at a glance:
1. This uses unsigned int for the chunk size, so the allocator will overflow on requests of 4GB or more despite taking a size_t. It seems that this is 32-bit only.
2. Even on 32-bit, the num_units calculation will overflow if you request (for example) 0xffffffff bytes of memory instead of returning an error.
3. None of this is thread-safe. It needs a global mutex lock.
4. EBP cannot be relied upon to yield anything sensible with -fomit-frame-pointer, which is common on 32-bit x86 as it brings the number of GPRs from 6 to 7.
- abcdef123xyz2 7y agoHe uses 32 bit pointers for the scan also, I think 32 bit only is intended. It also won't detect unaligned pointers :-). But this is someone's first try while learning about C or GC, he does says there will be mistakes!
- earenndil 7y ago> None of this is thread-safe. It needs a global mutex lock. Or have a separate allocation chain for each thread. It would increase fragmentation, but not by a lot, and probably increase performance by more than enough to make up for it.
- masklinn 7y agoTBF the author is pretty clear in their introduction: > our code will be dependent on the Linux kernel […] 32-bit and not one bit more […] Please don't use this code. I did not intend for it to be wholly correct and there may be subtle bugs I did not catch. because the use of sbrk also seems like a pretty bad idea.