)]}'
{
  "commit": "5b845de636224ef3e065be8e1c7d2df3389aa175",
  "tree": "ac11056d78e1be7bf38ab48fa94e44226a99ce0b",
  "parents": [
    "dd9ee6068667ca58c8d6f1c1cea617fd69452ecf"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Sat Jan 07 23:21:52 2023 -0800"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Tue May 16 18:53:51 2023 +0000"
  },
  "message": "Use Windows Interlocked* APIs for refcounts when C11 isn\u0027t available\n\nRight now, MSVC has to fallback to refcount_lock.c, which uses a single,\nglobal lock for all refcount operations. Instead, use the Interlocked*\nAPIs to implement them.\n\nThe motivation is two-fold. First, this removes a performance cliff when\nbuilding for Windows on a non-Clang compiler. (Although I\u0027ve not been\nable to measure it in an end-to-end EVP benchmark, only a synthetic\nrefcount-only benchmark.)\n\nMore importantly, it gets us closer to assuming atomics support on all\nnon-NO_THREADS configurations. (The next CL will clear through that.)\nThat, in turn, will make it easier to add an atomics-like abstractions\nto some of our hotter synchronization points. (Even in newer glibc, with\nits better rwlock, read locks fundamentally need to write to memory, so\nwe have some cacheline contention on shared locks.)\n\nAnnoyingly, the Windows atomic_load replacement is not quite right. I\u0027ve\nused a \"no-op\" InterlockedCompareExchange(p, 0, 0) which, empirically,\nstill results in a write. But a write to the refcount cacheline is\nsurely better than taking a global exclusive lock. See comments in file\nfor details. OpenSSL uses InterlockedOr(p, 0), but that actually results\nin even worse code. (InterlockedOr needs a retry loop when the\nunderlying cmpxchg fails, whereas InterlockedCompareExchange is a single\ncmpxchg.)\n\nHopefully, in the future (perhaps when we require VS 2022\u0027s successor,\nbased on [1]), this can be removed in favor of C11 atomics everywhere.\n\n[1] https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual-studio-2022-version-17-5-preview-2/\n\nBug: 570\nCq-Include-Trybots: luci.boringssl.try:linux_clang_rel_tsan\nChange-Id: I125da139e2fd3ae51e54309309fda16ba97ccf20\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59846\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "bc307023c9ff38cb850abacb0f08a2bce833e481",
      "old_mode": 33188,
      "old_path": "crypto/CMakeLists.txt",
      "new_id": "12d15a84eb0261d3d651d3e0d5169a409a90ad1a",
      "new_mode": 33188,
      "new_path": "crypto/CMakeLists.txt"
    },
    {
      "type": "modify",
      "old_id": "a4cd929125e6d882ed68dc528a9afb45f6c211cd",
      "old_mode": 33188,
      "old_path": "crypto/internal.h",
      "new_id": "adcd444353a1a1896f4c9037790d76fffb54ab89",
      "new_mode": 33188,
      "new_path": "crypto/internal.h"
    },
    {
      "type": "modify",
      "old_id": "173267e382b915df9d3b14a813f3157cd93ee34b",
      "old_mode": 33188,
      "old_path": "crypto/refcount_lock.c",
      "new_id": "7886bf8997d881f49374b6457cf93c13a83bd77e",
      "new_mode": 33188,
      "new_path": "crypto/refcount_lock.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "7a2740bc266a8355578ea928dbd63e9a30e868d7",
      "new_mode": 33188,
      "new_path": "crypto/refcount_win.c"
    }
  ]
}