This was a regression in bf65624298 that caused crashes on startup in static builds due to the "small" DeletedBufferChain array not being initialized early enough
For some reason it wasn't being constant-initialized, it is now by setting the _buffer_size field to 0 initially and changing it later in get_deleted_chain
init_memory_hook() is no longer required, eliminating static initialization order issues
This required moving the DeletedBufferChain map elsewhere, which now also has a const-initialized array for relatively small allocations.
Also, deletedChain.T has been renamed to deletedChain.I
Fixes#539
Matching makepanda, this avoids symbol conflicts and may have optimization benefits.
This is a temporary hack until CMake 3.24 is released, which offers a cleaner way of doing this.
Adds patomic_signed_lock_free, patomic_unsigned_lock_free, and patomic_flag with wait/notify methods modelled after C++20. Implemented using futexes, falling back to a mutex+condition variable hash table if not supported. (Currently the hash table has a fixed size of 64, which we could increase if necessary, but we really shouldn't even have a fraction of that number of simultaneously sleeping threads...)
Other atomic types are unaffected at the moment, in part because futexes are really restricted to 32-bit ints on Linux anyway
Partial backport of 07545bc9e3 for Windows, requires building with `--override USE_MEMORY_MIMALLOC=1 --override USE_DELETED_CHAIN=UNDEF` for optimum effect
Windows' malloc has awful performance. mimalloc is orders of magnitude faster, even faster than DeletedBufferChain. Therefore, only enable USE_DELETED_CHAIN on Windows when building without mimalloc.
On Linux, mimalloc doesn't appear to be measurably faster than glibc's own allocator. Both are marginally than DeletedBufferChain, though, and substantially faster in the multi-threaded case, so USE_DELETED_CHAIN is disabled there in all cases.
This typedefs to std::atomic<> when building with true threading, and uses a dummy implementation without.
This lets us use the full range of atomic operations offered by C++11, including explicit specification of memory fences. Using barriers lets the compiler generate more optimal code since currently we are using the quite strict sequential-consistent memory ordering for all operations. ReferenceCount has been changed to use the correct barriers (I hope). This may especially make a difference on weak ordering systems such as ARM.
Over time we should gradually replace the use of AtomicAdjust with the new patomic file.
Adds CMake support for the 54638bfc10 change.
One thing to note, compared to makepanda, is that CMake doesn't automatically rebuild the file if this env var is changed.
It's using a set purely keyed by number of remaining bytes, so if there are two pages with the exact same number of remaining bytes, one of them gets lost.
See #1077
It is a pervasive belief that using "delete" with a null pointer is safe, so our custom delete operators should also handle this case correctly.
This may fix regressions introduced by #934
rdb
Frang
Cary Sandvig
DJs3000
LD