Summary:
We only need as many slots as the number of L1 caches.

Also avoid allocating control blocks when the passed pointer has no managed object.

Reviewed By: philippv, luciang

Differential Revision: D29872059

fbshipit-source-id: 8c221b0523494c44a5c6828bafd26eeb00e573c4

Summary: This diff appears to work around a compiler bug in gcc10 with coroutines. GCC is not keeping alive a temporary passed to a coroutine function.

Reviewed By: nmagerko

Differential Revision: D29847926

fbshipit-source-id: 69e0fc4cece8f5d0e26647581800ad81b1e44c74

Summary:
This diff increases the number of domains that locally cache a context from
4 to 128. In effect, this stops sharing contexts between cores, and instead
causes each core to have its own context. (If a machine has fewer than 128
CPUs, the unused slots will never be initialized.)

This diff is an experimental tuning. We don't expect it to have large positive
or negative effects, but we do currently see a non-zero amount of CPU spent
contending on the underlying pool's mutex. So this is an attempt to address
that. We'll look at CPU after it has rolled out and assess the results.

Reviewed By: terrelln

Differential Revision: D29944813

fbshipit-source-id: 7b10cb9dd2c49c02fad1f680a1bea02747990796

Reviewed By: capickett

Differential Revision: D29942172

fbshipit-source-id: 98649f6bf911d2a7a2f0ac687fa51fe76e0b777c

Summary: Pull Request resolved: https://github.com/facebook/folly/pull/1611

Reviewed By: magedm

Differential Revision: D29938492

Pulled By: yfeldblum

fbshipit-source-id: d0fab63bdb59e714baaee2be15139f04958672d5

Summary: Remove single-use intermediate constants from SharedMutexImpl

Reviewed By: yfeldblum, ot

Differential Revision: D29934333

fbshipit-source-id: 5e4157fa1e6576f0fa9f2a2a10a32f0e1e24d7f5

Summary: The `folly::` prefix is not necessary from within folly's namespace and the `_v` is available on the folly trait even in C++14 builds when `std::is_trivially_copyable_v` from C++17 is unavailable.

Reviewed By: ot

Differential Revision: D29925029

fbshipit-source-id: 570d17c57ca68bea1c7c8b80ce59d8560b1aba2b

Summary: Right now the internal cancellation signal will be silently ignored, which hurts usability. Add mechanism for merging with external source and comment describing the pitfall.

Reviewed By: capickett

Differential Revision: D29935016

fbshipit-source-id: 9311930ff9fbfc0470fdcfb5d425f36e7f0aff06

Summary:
Change SharedMutexPolicyDefault to include max_spin_count and max_soft_yield_count instead of bool block_immediately.

Change the default spin and yield counts from 1000 and 1000 to 2 and 1, respectively.

Reviewed By: ot

Differential Revision: D29559594

fbshipit-source-id: 93a3bdf43c20f456031265daf7b76ab40e3dcbdf

Summary:
I don't really understand how FreeBSD allocates huge pages. There doesn't seem
to be any explicit mechanism to ask for them, other than `MAP_ALIGNED_SUPER`
which should just make the allocation aligned correctly? At any rate, this
should build and return FreeBSD to basically the way it worked before.

Fixes #1622.

Reviewed By: davidtgoldblatt

Differential Revision: D29915224

fbshipit-source-id: 9c5973714bd6ad3d1f0c6f3969ccdd23f17114e7

Summary: This was broken before D29680441 (https://github.com/facebook/folly/commit/832f135adede09d6e83e1f026c159d1b88249951)

Reviewed By: afernandez90

Differential Revision: D29913022

fbshipit-source-id: 5fa370a0ec3285875073ee84898601a41fff55e2

Reviewed By: rlyerly

Differential Revision: D29909431

fbshipit-source-id: 6ae0d7059e1f3c1ab0710d9472aec12dc324d620

Summary: It defines several generically named macros, better avoid including it everywhere.

Reviewed By: aary

Differential Revision: D29870524

fbshipit-source-id: b8703a737a6dc53e00c13daebc445855bfbadd1f

Summary:
SSLException derives from AsyncSocketException, so need to construct the exception_wrapper differently to prevent slicing it.

I wish there were a more future-proof way to do this

Reviewed By: yangchi

Differential Revision: D29836520

fbshipit-source-id: df4222d94952c66b4c86f12861b3792babdce3c6

Summary:
There are two problems with the current approach of returning Try<T>:
- It is impossible to write generic algorithms like coro::timeout that convert any awaitable into a Task of its await result without throwing exceptions because there's no way to reconstruct the expected return type. More generally, we want the property that the await_try_result_t::element_type matches the await_result_t so we can make drop-in replacements by wrapping in functions like timeout.
- There's no way to both avoid moving yielded values and avoid throwing exceptions because Try doesn't support references (and an earlier diff adding this support was rejected), which means the two performance optimizations avaioable to users of AsyncGenerator are mutually exclusive

We fix this to restore the aforementioned invariant by wrapping the existing result type. This is a marginal inefficiency, so if we notice regressions as a result we can specialize these Try instantiations to consolidate the storage. For now we do not except this to matter.

Reviewed By: andriigrynenko

Differential Revision: D29680441

fbshipit-source-id: 4ef74f4645d990b623bb95a297718fb576a9b977

Summary: `RequestContext::StaticContextAccessor` acts as a guard, preventing all threads with a `StaticContext` from being destroyed (or created).

Reviewed By: dtolnay

Differential Revision: D29684337

fbshipit-source-id: 2b785b9293dd0b9c190512363afddaff50ec1f01

Summary:
The class depends on RTTI. It's a sanity check that crashes if two instances of a singleton are created. So doing nothing in `-fno-rtti` code is fine.

Redo of D29630207 (https://github.com/facebook/folly/commit/160eb4d284eb67cc2641b6718c964dab8fc6486b)

Reviewed By: dtolnay

Differential Revision: D29684338

fbshipit-source-id: 38355df5297681329f227fd10570a816f4672b9b

Summary: We use the FromBla to distinguish collect-range (type fixed, count varies) algorithms from collect-tuple (types vary, count fixed) algorithms. But in this case there is no sensible translation from collect-tuple to an async-generator so the from-range bit is not necessary.

Reviewed By: vitaut

Differential Revision: D29877021

fbshipit-source-id: 69dfa764fca880bd3770a4d57ff0d60fe500a206

Summary: `CoreCachedSharedPtr` is almost as fast as `ReadMostlySharedPtr`, so we can use it to have a better default that does not have pathological behavior under heavy contention. `try_get_fast()` is still useful if we need to squeeze out the last cycle.

Reviewed By: philippv, luciang

Differential Revision: D29812053

fbshipit-source-id: 49e9e53444f8099dbfe13e36c3c07c1b57bb89fb

Summary:
BMI2 (`pdep`) varint encoding that's mostly branchless. It's 2-5x faster than the current loop-unrolled version.

Being mostly branchless there's less variability in micro-benchmark runtime compared to the loop-unrolled version:
- the loop-unrolled versions are slowest when encoding random numbers across the entire 64-bit range (some likely large) and branch prediction has most failures.

Kept the fast-pass for values <127 (encoded in 1 byte) which are likely to be frequent. I couldn't find a fully branchless version that performed better anyway.

TLDR:
- `u8`: unroll the two possible values (1B and 2B encoding). Faster in micro-benchmarks than branchless versions I tried (needed more instructions to produce the same value without branches).
- `u16` & `u32`:
-- u16 encodes in up to 3B, u32 in up to 5B.
-- Use `pdep` to encode into a u64 (8 bytes). Write 8 bytes to `QueueAppender`, but keep track of only the bytes that had to be written. This is faster than appending a buffer of bytes using &u64 and size.
-- u16 could be written by encoding using `_pdep_u32` (3 bytes max fit in u32) and using smaller 16B lookup tables. In micro-benchmark that's not faster than using the same code as the one to encode u32 using `_pdep_u64`. In prod will perform better due to sharing the same lookup tables with u32 and u64 versions (less d-cache pressure).
- `u64`: needs up to 10B. `pdep` to encode first 8B and unconditionally write last 2B too (but keep track of `QueueAppender` size properly).

Reviewed By: vitaut

Differential Revision: D29250074

fbshipit-source-id: 1f6a266f45248fcbea30a62ed347564589cb3348

Summary:
I've created an abstract class called `OpenSSLTicketHandler` to which the
server's ssl context dispatches ticket crypto preparation. This means that
changing the configuration of how tickets are encrypted can be changed by
using a different implementation of the handler.

This abstraction is sort of broken by all the set and get APIs on the context
that modify ticket secrets, rather than properly abstracting this detail into
a concrete impl of the handler (e.g. a `TLSTicketKeyManager` can manage secrets
from a file and not require users to pass all these secrets down from the
acceptors). For now though we rely on (checked!) dynamic casts to get a
`TLSTicketKeyManager` from which we can freely modify the secrets.

Reviewed By: mingtaoy

Differential Revision: D24686664

fbshipit-source-id: fb30941982fb3114e2aba531372a9d35ccc0ee48

Summary:
This diff switches the JemallocHugePageAllocator to permit initially reserving
a (very) large contiguous region of virtual address space, which can then be
progressively backed by huge pages on demand.

This is intended to increase the flexibility of the allocator. In particular,
this should enable automatic initialization of the JHA without having to
carefully and correctly size the arena. (Assumption: `mmap()`'ing a big chunk
of address is cheap, right? Although even if it is this is probably something
we should only do for long-lived processes. Identifying "long-lived processes"
and triggering initialization in them is itself an open topic to be addressed
in a subsequent diff.)

The concern here is that this potentially moves `madvise(..., MADV_HUGEPAGE)`
calls later into the process lifetime, when memory pressure/fragmentation may
be greater. This might induce stalls in the process? This can be mitigated
using the existing pattern of explicitly calling `::init()` in your processes'
`main()`. This will commit the requested pages.

Context: I intend to use this allocator to back allocations in the Zstd
Compression Context Singletons.
(`folly/compression/CompressionContextPoolSingletons.cpp`)

Feedback on the approach taken here is greatly appreciated!

Reviewed By: davidtgoldblatt

Differential Revision: D29502147

fbshipit-source-id: 814e1ba3544cf5b5cfb67a08abd18f940255362f

Summary:
Currently `CoreCachedWeakPtr` only exposes `get()`, which returns by value, so to lock the pointer we need to do two refcount operations, one on the weak count and one on the shared count. This is expensive.

We could return by `const&`, but I don't want to expose the internal state, as we may be able to optimize the footprint by relying on implementation details of `std::shared/weak_ptr` in the future.

Instead, expose a natural `lock()` method.

Also, improve the benchmarks:
- Add comparison with `ReadMostlySharedPtr`
- Ensure that all threads are busy for the same time, so that wall time * `numThreads` is a good approximation of overall CPU time.

Reviewed By: philippv

Differential Revision: D29762995

fbshipit-source-id: 851a82111e2726425e16d65729ec3fdd21981738

Summary:
`asString()` returns a string by value, which means a copy of the string must be made.

We don't actually need to do this at all:
- We know that the dynamic contains a string, thanks to the switch statement
- The function being called with the result, `escapeString`, only wants a StringPiece anyway.

So this copy is a waste. And uses significant CPU in my application.

Reviewed By: ispeters

Differential Revision: D29812197

fbshipit-source-id: 60df668f7501f78f4282717d6896cd891950b6f5

Reviewed By: capickett

Differential Revision: D29764496

fbshipit-source-id: 855bcfc749358d3754b604e417cf5512a91ab6df

Reviewed By: Liang-Dong

Differential Revision: D29784019

fbshipit-source-id: f7516603bc73b33ad7c57da1103451f75f8566b4

Summary: Add async stack trace to `CO_TEST_P`

Reviewed By: ispeters

Differential Revision: D29800378

fbshipit-source-id: ce7a22f545f2a55bd02ad5535f29aea094063bfe

Co-authored-by: Facebook Community Bot <6422482+facebook-github-bot@users.noreply.github.com>

Summary:
As per title

CVE-2021-24036

Reviewed By: jan

Differential Revision: D27938605

fbshipit-source-id: 7481c54ae6fbb7b67b15b3631d5357c2f7043f9c

Summary: Dump async stacks on uncaught exception from CO_TEST_

Reviewed By: ispeters

Differential Revision: D29775971

fbshipit-source-id: 80e349aa411d8b866747d1821b215adfbc51b53f

Reviewed By: spalamarchuk

Differential Revision: D29784994

fbshipit-source-id: 0faac9c21f56061d8d787f8bd4e2e61ed5fcaf6c

Summary:
The current implementation of function stubs in `SocketFileDescriptorMap.cpp` generates the following build errors:
```
stderr: xplat/folly/net/detail/SocketFileDescriptorMap.cpp:171:3: error: 'socketToFd' has a non-throwing exception specification but can still throw [-Werror,-Wexceptions]
  throw std::logic_error("Not implemented!");
  ^
xplat/folly/net/detail/SocketFileDescriptorMap.cpp:170:30: note: function declared non-throwing here
int SocketFileDescriptorMap::socketToFd(void* sock) noexcept {
```
because the methods are stubbed out to throw and exception even though they are marked as `noexcept`.

To fix the warning the subbing implementation is changed to call `std::terminate()` instead of throwing an exception. According to the language specification (https://en.cppreference.com/w/cpp/language/noexcept_spec) this should not result in any change in run-time behavior, since throwing and exception in a method marked as `noexcept` is effectively a call to `std::terminate()`.

Differential Revision: D29687674

fbshipit-source-id: 77405d8a31e45c8836e8746c9b25e12ef06335c4

Summary: allow users to set/append a list of cmsgs to be sent for each write

Reviewed By: bschlinker

Differential Revision: D29313594

fbshipit-source-id: 8f78c59ecfe56ddb2c8c016d6105a676cd501c18

Summary: This diff adds AsyncSSLSocket::setSupportedProtocols, analagous to SSL_set_alpn_protos, which allows connection specific ALPNs to be set. Prior to this diff, there was no easy way to change the set of ALPNs to use other than creating a separate SSLContext or manually using the low level OpenSSL interface.

Reviewed By: mingtaoy

Differential Revision: D29247716

fbshipit-source-id: 6f378b4fc75f404e06fe0131ab520b7e4b8f33b6

Summary: Add support for Subprocess to call sched_setaffinity

Reviewed By: yfeldblum

Differential Revision: D29722725

fbshipit-source-id: b0d4577bf3caaeb65137c8168bd27e1f402969da

Summary: Prepares for next diff

Reviewed By: Mizuchi

Differential Revision: D29665910

fbshipit-source-id: 1026b0836ca803d566086ab9ed8e13e36d607c5f

Summary: Passing large `key` doesn't correctly advance position to the end.

Reviewed By: ot

Differential Revision: D29712973

fbshipit-source-id: 7da7c49250753c12f3703ccf49107e56bf841131

Summary:
If one of the input futures is off the end of a folly::Executor::weakRef()
executor, then there is a chance that it may never complete with a value or an
ecception.  In this case, collect() would crash because it assumes that the
folly::Try instances for all input futures have either a value or an exception.

Fix that case by injecting a BrokenPromise exception for the case where a future
never has an exception or a value.

Reviewed By: yfeldblum

Differential Revision: D26989091

fbshipit-source-id: b810fe4d5d071233da1f453b3759991e057d78c6

Summary: `UniqueInstance.cpp` has its own `PtrRange` which it exclusively uses.

Reviewed By: yfeldblum, Mizuchi

Differential Revision: D29685352

fbshipit-source-id: 32658b3ee6fc1830c2c2f27693baefa16026f13e