Add exception handling for new operator

[mjp41]

The new operator in the snmalloc did not throw exceptions in the case of allocation failure. Moreover, it was not possible to override the behaviour of the failure of the new operator using the std::set_new_handler function.

This commit adds the necessary code to the snmalloc new operator to throw std::bad_alloc when the allocation fails. It also allows the std::set_new_handler function to be used to set a custom handler for allocation failures.

The PR also adds a new build target libsnmalloc-minimal.so that does not override new. This has smaller dependencies.

[mjp41]

Addresses #785

[SchrodingerZhu]

There are both throwing and non-throwing variants of the new operator:

https://en.cppreference.com/w/cpp/memory/new/operator_new

Is the idea that even for the throwing one, we will also actively avoid adding any additional branch in the fast path?
Is it possible to separate the throwing ones in a different TU/Shim?

[mjp41]

There are both throwing and non-throwing variants of the new operator:

https://en.cppreference.com/w/cpp/memory/new/operator_new

Is the idea that even for the throwing one, we will also actively avoid adding any additional branch in the fast path?

Yes, the template parameter:

template<bool ShouldThrow = true>

https://github.com/microsoft/snmalloc/pull/791/files#diff-d40107b20785f1091aa8d32178beac25eac712d3c2934f4c5d8cce7c6b3343d6R26

Basically creates two versions of the failure continuation, one that throws, and one that doesn't. Then

void* operator new(size_t size)
{
  return snmalloc::alloc<snmalloc::Throw>(size);
}

will throw without a branch, and

void* operator new(size_t size, std::nothrow_t&)
{
  return snmalloc::alloc<snmalloc::NoThrow>(size);
}

will not throw. They will both call the function returned by get_new_handler.

Is it possible to separate the throwing ones in a different TU/Shim?

That is a good idea. I am not sure quite what the right default is, and what to leave in libsnmallocshim.so. I am wondering if it should be

• libsnmallocshim.so doesn't do the C++ overrides, but we provide a second library
• libsnmallocnew.so that does provide the C++ overrides and has the exception stuff linked in.

What do you think?

[mjp41]

I also have no idea how I have broken the Bazel build again.

[SchrodingerZhu]

libsnmallocnew.so sounds good.

[mjp41]

@SchrodingerZhu, so after some experiments,

• if we statically link libstdc++,
• dynamically link libgcc_s,

Then I believe we get valid exception behaviour, and the memory footprint does not increase. If we dynamically link libstdc++, then the memory footprint increases by 1-2Mb.

I am tempted to just make this the default going forward.

@davidchisnall pinging you, in case you have opinions on this.

[mjp41]

@SchrodingerZhu I think this is stable now. I found a few places where the codegen was not doing tail calls, but now I have it working nicely I think. Discovering the noexcept(noexcept(<expr>)) pattern to enable templating of whether the function is noexcept or not was a massive help/relief.

[SchrodingerZhu]

LGTM. I like the way how noexcept gets propagated.