)]}'
{
  "commit": "fbf19b6cc611f08b41cd7ef2e524b8f64d8ffbb8",
  "tree": "47779ada4188211d57952de15fcd9d6bd2e6fa53",
  "parents": [
    "e95749bd0d5579d1e87eaef0d667f23591bf3521"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Mon May 12 15:09:45 2025 -0400"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Fri May 23 11:14:20 2025 -0400"
  },
  "message": "gdb/dwarf: split dwo_lock in more granular locks\n\nThe dwo_lock mutex is used to synchronize access to some dwo/dwp-related\ndata structures, such as dwarf2_per_bfd::dwo_files and\ndwp_file::loaded_{cus,tus}.  Right now the scope of the lock is kind of\ncoarse.  It is taken in the top-level lookup_dwo_unit function, and held\nwhile the thread:\n\n - looks up an existing dwo_file in the per-bfd hash table for the given\n   id/signature\n - if there\u0027s no existing dwo_file, attempt to find a .dwo file, open\n   it, build the list of units it contains\n - if a new dwo_file was created, insert it in the per-bfd hash table\n - look up the desired unit in the dwo_file\n\nAnd something similar for the dwp code path.  This means that two\nindexing thread can\u0027t read in two dwo files simultaneously.  This isn\u0027t\nideal in terms of parallelism.\n\nThis patch breaks this lock into 3 more fine grained locks:\n\n - one lock to access dwarf2_per_bfd::dwo_files\n - one lock to access dwp_file::loaded_{cus,tus}\n - one lock in try_open_dwop_file, where we do two operations that\n   aren\u0027t thread safe (bfd_check_format and gdb_bfd_record_inclusion)\n\nUnfortunately I don\u0027t see a clear speedup on my computer with 8 threads.\nBut the change shouldn\u0027t hurt, in theory, and hopefully this can be a\npiece that helps in making GDB scale better on machines with many cores\n(if we ever bump the max number of worker threads).\n\nThis patch uses \"double-checked locking\" to avoid holding the lock(s)\nfor the whole duration of reading in dwo files.  The idea is, when\nlooking up a dwo with a given name:\n\n - with the lock held, check for an existing dwo_file with that name in\n   dwarf2_per_bfd::dwo_files, if found return it\n - if not found, drop the lock, load the dwo file and create a dwo_file\n   describing it\n - with the lock held, attempt to insert the new dwo_file in\n   dwarf2_per_bfd::dwo_files.  If an entry exists, it means another\n   thread simultaneously created an equivalent dwo_file, but won the\n   race.  Drop the new dwo_file and use the existing one.  The new\n   dwo_file is automatically deleted, because it is help by a unique_ptr\n   and the insertion into the unordered_set fails.\n\nNote that it shouldn\u0027t normally happen for two threads to look up a dwo\nfile with the same name, since different units will point to different\ndwo files.  But it were to happen, we handle it.  This way of doing\nthings allows two threads to read in two different dwo files\nsimulatenously, which in theory should help get better parallelism.  The\nsame technique is used for dwp_file::loaded_{cus,tus}.\n\nI have some local CI jobs that run the fission and fission-dwp boards,\nand I haven\u0027t seen regressions.  In addition to the regular testing, I\nran a few tests using those boards on a ThreadSanitizer build of GDB.\n\nChange-Id: I625c98b0aa97b47d5ee59fe22a137ad0eafc8c25\nReviewed-By: Andrew Burgess \u003caburgess@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b1849b9b071d34645cbcc2b9a74c0f0487e51bab",
      "old_mode": 33188,
      "old_path": "gdb/dwarf2/read.c",
      "new_id": "c02b9cffbc06ed8015adf0a791ea0793b96059a7",
      "new_mode": 33188,
      "new_path": "gdb/dwarf2/read.c"
    },
    {
      "type": "modify",
      "old_id": "aaac5e7cbbfc6ae1dab321c89fa2918c8e45b66b",
      "old_mode": 33188,
      "old_path": "gdb/dwarf2/read.h",
      "new_id": "e676d64f2e981bcbaec2bdc933fa84fdd0d5b7ef",
      "new_mode": 33188,
      "new_path": "gdb/dwarf2/read.h"
    }
  ]
}