ckennelly

With restartable sequences in Linux, there is no need for mutexes or RMW atomics. The mutual exclusion is guaranteed by the kernel.

TCMalloc has different abort handlers for each function: If preempted, we need to know where to restart.

If `rseq_cs` is no longer describing a relevant address, that is, the program counter has moved past it, the kernel just ignores it.

TCMalloc TL here :)

The code is executed by a single thread. Everything retires in program order. There is no need for a memory barrier between starting the critical section and its body.

It depends on your STL implementation's representation of string: https://godbolt.org/z/nMYGYoWbq

* libstdc++ has an internal reference to its own address for the SSO. If the moved-from string was referencing its SSO buffer, the moved-to string needs to use its own address. The branch is differentiating the SSO state from a heap-allocated state.

* libc++ string move can be implemented this way, but the branch ends up happening on access to the string. It still needs to discard the old heap allocated buffer, if need-be as well.

The default setting of max_ptes_none is also problematic.

On a stock kernel, it's 511. TCMalloc's docs recommend using max_ptes_none set to 0 for this reason: https://github.com/google/tcmalloc/blob/master/docs/tuning.m...

(Disclosure: I work on TCMalloc and authored the above doc.)

As mentioned in that Stack Overflow post, though, things change again with FSRM (Fast Short Rep Mov).

While there are still startup costs, the overhead of calling a function (especially via a PLT) and incurring instruction cache misses is hard to demonstrate in a microbenchmark, while rep movsb encodes more compactly than many flavors of call. In an actual application though, the "slower" but smaller implementation can often win (https://research.google/pubs/pub50338.pdf and https://research.google/pubs/pub48320.pdf)

https://research.google/pubs/pub50338.pdf goes into more depth on the mem* libc functions and principles for the implementations in llvm libc.

llvm-libc's memcpy is heavily sized optimized for this reason. A dedicated instruction that is fast for all cases, is ideal, though.

You can still get a benefit from sized delete, even without inlining.

Dynamic linking requires calling through the PLT to get to the implementation, so there's a data dependency on determining where the code for it is.

Independent of inlining (with LTO, since the C++ language rules requires inhibit optimizing out "operator new"), the static call is far simpler.

The cost in applications really does add up.

"Profiling a warehouse-scale computer" (by S. Kanev, et. al.) showed several % of CPU usage allocating and deallocating memory. While a malloc and free does have some data dependencies, the indirect jump (by dynamically linking) is an avoidable cost on the critical path by statically linking.

This is the modern version--based on Abseil--that we use in production for practically every C++ binary. It includes a number of performance optimizations (per-CPU caches, an improved fast/slow path, and a hugepage-aware backed), along with improved telemetry (a low overhead, always-on heap profiler, for example).

gperftools includes a decade+ old copy of TCMalloc and several other things (a signal-based CPU profiler, a heap checker, etc.). The two have diverged significantly.

They're not confidence intervals, but weather.gov's forecasts include a link to the NWS office's forecast discussion (updated every few hours). This can give you a bit of insight into forecaster uncertainty and the variation between models.

To excerpt the most recent (8:14PM EDT) NYC office's discussion:

"As a result, expect most precipitation to be focused mainly during the evening hours. Hi-resolution models have been suggesting that the overnight hours could be mainly if not entirely dry. This is due to 850 hPa warm front lifting to the north by around 6z and a dry slot moving in from the SW (DC/PHI area). For now, have just lowered pops to chance. If trends in the high resolution models hold, pops will need to be lowered further if not removed for the overnight hours with future updates."

Thanks for taking a look.

To go through your points:

* If the "wrong" GPG binary is loaded, the game is likely already up: If an attacker has that degree of control over your machine, they're already on the other side of this airtight hatchway. They can attach to your running programs, read memory contents, and so forth, so compromising the GPG binary isn't necessary.

* Keys are handled by GPG, which normally should mlock key material.

* Part of my plan to switch to handling pages (rather than allowing data to be managed via a std::string) was to be able to use mlock() properly. I'll be adding that soon.

* Since the GPG binary is running as you, it could do Bad Things to the underlying filesystem (or filesystem exported by FUSE), but you do raise a point about closing file descriptors for general cleanliness.