On platforms that support low-memory notifications register callbacks
that perform lazy decommit. This allows idle processes to return memory
to the OS. Without incurring the cost of constantly committing and
decommitting memory.
Code review and CI changes
* Fixed test to use a template to make constexpr magic work
* Factored out basic notification mechanism so can be reused on other
platforms.
If the external thread statics are used, then
we don't need to include some C++ runtime
concepts. This refactoring moves some global initialization under
conditional compilation.
Windows is only sending low-memory notifications when the machine
is reaching low-memory. So running a 32bit process on 64bit machine
can easily exhaust address space before machine gets close to
low-memory.
The low-memory notification was getting into an infinite loop. This
fixes the loop termination, and provides a test for platforms which
support low-memory notification.
On platforms that do not support aligned mmap/VirtualAlloc,
we need to produce heavily aligned blocks to guarantee we can meet
all possible alignment requests.
This commit grabs a block much larger than requested, and then produces
"offcuts" before and after the block of smaller/same "large_classes". This
enables one mmap/virtual alloc request to services many other requests
for aligned memory.
The PAL API previously allowed for returning more memory than asked for.
This was when the PAL performed the alignment work, now this is done in
large alloc, so removing from the PAL.
* Removing option as not supported by CI
Will migrate CI forward and readd.
* Made failure for clang-format errors.
* Improved handling of errors during CI.
* Prevent failures escaping.
* Clang-format fix
* Remove stderr
* Update azure-pipelines.yml
Co-Authored-By: Paul Liétar <plietar@users.noreply.github.com>
Co-authored-by: Paul Liétar <plietar@users.noreply.github.com>
Fixes a few places where Clang complains about Windows specific code,
and also uses macros supported by Clang on Windows. A few places
separating platform and compiler specific code, as MSVC and WIN32 were
used interchangably previously.
* add rust support
* move aligned_size to sizeclass.h
* add static qualifier
* adjust CMakeLists.txt, may broke CI tests
* fix msvc's complaining on c++17
* use SNMALLOC_FAST_PATH as the decorator of aligned_size
* adapt new alignment algorithm and add related test
Co-authored-by: mjp41 <mattpark@microsoft.com>
* fix test cases for msvc
* add extra test for size == 0
* treat memory block of same sizeclass as the same
* fix formatting problem
* remove extra declarations
Co-authored-by: Matthew Parkinson <mjp41@users.noreply.github.com>
If the test happens as uintptr_t on CHERI, then we attempt to construct
a capability and use a capability-based test rather than an
integer-based one, and things go south.
posix_memalign requires that the alignment parameter be a multiple of
sizeof(uintptr_t), but the test begins with alignments as small as
sizeof(size_t). While those are very likely the same value out in the
wild right now, they're not on CHERI.
Begin the test loop at sizeof(uintptr_t) and add a test that a request
for a reasonable amount of memory but with an alignment of
sizeof(uintptr_t)/2 fails with EINVAL.
If some tests on Windows are co-scheduled, then they run out of commit
space and crash. For example, in func-memory,
test_external_pointer_large can cause the small CI machines to run out
of commit space on Windows.
Made the API so that get always returns an initialised Alloc*. Added
new fast path that doesn't perform checking, but can lead to very slow
behaviour if called and reused.
By caching the result of the first call to ThreadAlloc::get(), we were
always hitting a code path that should be hit once per thread in normal
operation.
Copying an idea from mimalloc, initialise the TLS variable to a global
allocator that doesn't own any memory and then lazily check when we hit
a slow path (which we always do when using the global allocator, because
it doesn't own any memory) if we are the global allocator and replace
it.
There is a slight complication compared to mimalloc's version of this
idea. Snmalloc collects outgoing messages and it's possible for the
first operation in a thread to be a free of memory allocated by a
different thread. We address this by initialising the queues with a
size value indicating that they are full and then do the lazy check when
about to insert a message that would make a queue full. This will then
trigger lazy creation of an allocator.
Global initialisation doesn't work for the fake allocator, so skip most
of its constructor.
This is useful as codegen is nicer if we use size_t, but the semantics
is uint8_t, and is stored as that in many places in the metadata.
Ultimately should introduce a wrapper to check this invariant.
- Don't run an expensive functionality test in debug builds.
- Don't run the different cache configurations (they're probably going
away soon because they help only in synthetic benchmarks).
The PAL can now advertise that it supports aligned allocation. If it
does not, then the memory provider will do the alignment for it.
This change still leaves the PAL responsible for systematic testing, but
it should now be much easier to lift that out.
