PallHaraldsson
commented
1 year ago The StaticCompiler has a problem, it take in n from input, so may overwrite memory... since fixed 100 bytes allocated and not extended.
Another issue for both types of alloc is that I would align, like to 64-byte boundary (a cache-line boundary, I guess malloc would do that, it might be best for performance), at least to 8-byte, you don't want misaligned loads, in case some would allocate e.g. one byte. It would work, just slower on x86, but would be an error on some architectures.
MasonProtter
I see that you want nothrow for StaticCompiler.jl, but there are some problems.
It will overwrite memory if you're not careful. I'm thinking you may want to check if the buffer is to small, and then there might be a way to rather just exit the program? I think you can print something on stderr first, and then exit(1), or is there some PANIC, similar to in Go?
While alloc_nothrow works in regular Julia, just not vice versa, why it exists, I think the functionality above could be folded into the regular alloc. If you really need to use the other Malloc, could you use that in all cases? It means an extra dependency on the other package, or maybe rather use Libc.malloc directly? You can use Libc.realloc, and then you need to use the best growing strategy yourself, but you already have one.
I'm not sure what using Julia's regular Vector buys you, then it will be tracked by Julia's GC, probably a minimal slowdown though, with no benefit, since you don't want your buffers reclaimed anyway. And it's just an array of bytes, can't contain pointers to other objects. Or actually it may be possible, but then will not be be considered by the GC anyway.