)]}'
{
  "log": [
    {
      "commit": "65c18a21e7cb0d48327788df498f15ae195e9e3c",
      "tree": "ba49c1f07e7cd2bc6d9ffbafc184bcad85e9ce45",
      "parents": [
        "c4d13ae39ec6f4b6b76b152818516081beb6bb56"
      ],
      "author": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Fri Jan 03 23:37:13 2020 +0000"
      },
      "committer": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Tue Jan 07 17:40:19 2020 +0000"
      },
      "message": "Revert^4 \"Add spin loop to mutex, overhaul monitor\"\n\nThis reverts commit ead89ef62768faa06fedd279b86bccbed1464673.\n\nPS1 is identical to Revert^2.\n\nThis fixes a shutdown issue caused by prematurely hanging when we\nblock while trying to acquire system mutexes during shutdown.\n\nOnly refuse to wake up after shutdown is well under way.\n\nBug: 140590186\nBug: 121302864\nTest: Build and boot AOSP.\nTest: art/test/testrunner/testrunner.py --host -b -t 1932-monitor-events-misc\nTest: art/test/testrunner/testrunner.py --host -b -t 004-ThreadStress\nTest: art/test/testrunner/testrunner.py --host -b -t 132-daemon-locks-shutdown\nTest: 132-daemon-locks-shutdown repeated with increased thread counts and multiple\nconcurrent tests.\n\nChange-Id: Ic19d32652a2a05c1ca843b3e9c6e29e6770262da\n"
    },
    {
      "commit": "ead89ef62768faa06fedd279b86bccbed1464673",
      "tree": "27e3bef919a0775f45c0dfc08b6a26d7688e8a98",
      "parents": [
        "8d94dddfd60ab8122b0abb1a0d90fb13d752a7b6"
      ],
      "author": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Fri Jan 03 21:37:10 2020 +0000"
      },
      "committer": {
        "name": "Treehugger Robot",
        "email": "treehugger-gerrit@google.com",
        "time": "Fri Jan 03 22:50:59 2020 +0000"
      },
      "message": "Revert^3 \"Add spin loop to mutex, overhaul monitor\"\"\n\nThis reverts commit 3d52abe40e619497b1b59cfce92c74b5a417add5.\n\nReason for revert: Causes asan build timeout; Apparently the runtime\ngoes away while we\u0027re holding a system mutex. We now sleep forever\nwithout releasing it.\n\nBug: 140590186\nBug: 121302864\nChange-Id: I9e4dcaf820815c751aa803473809955451988ebd\n"
    },
    {
      "commit": "3d52abe40e619497b1b59cfce92c74b5a417add5",
      "tree": "50c67eb9a980b1525f78e03d0941605bb9fa3887",
      "parents": [
        "eac38a141a95adc273059ba2f6ad26f073391ed3"
      ],
      "author": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Tue Nov 19 18:49:50 2019 +0000"
      },
      "committer": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Fri Jan 03 19:15:21 2020 +0000"
      },
      "message": "Revert^2 \"Add spin loop to mutex, overhaul monitor\"\n\nThis reverts commit d56f7d1086b16f32c0771a41a4afb376b5fd3076.\n\nReason for revert: PS2 fixes the problems I identified.\n\nPS1 is straight revert^2 of, and thus identical to aosp/1111800.\n\nPS2 in addition:\n- Reduces the size of the test, when not modified to run as benchmark.\n- Disables the test in slow-running configurations, which timed out.\n- Stops using the mutex recursion count, and instead reintroduces\n  one at the monitor level. The plan is to eliminate the one in mutex\n  in a future CL.\n- Avoids modifying various monitor fields in suspended state.\n  MonitorInfo, deflation, etc., may look at the state of a suspended\n  thread and expect not to race. I don\u0027t think the original code had\n  this completely correct either, but PS1 made it worse.\n- Documents some aspects of the code that confused me at times.\n- Avoids dereferencing the monitor owner Thread* unless it holds the\n  thread list lock, and thus knows that the thread won\u0027t go away.\n- Stores a Thread* instead of a thread_id with the monitor owner method\n  and dex pc information used for debugging. This is required to avoid\n  extra thread list lock acquisitions, since we need to dereference the\n  owner to get the thread id.\n- Makes the thread list Contains method public, again in order to\n  support the above. (This ignores C/C++ restrictions on dangling\n  pointer use. We already rely on violating those elsewhere, and\n  the committees are trying to get their story straight about this.)\n- Causes the spin loop to give up immediately if the process is\n  shutting down. This gets us to an actual idle state sooner in that\n  case, and should hopefully mitigate the shutdown issues somewhat.\n  (We tried not spinnning in \"suspended\" state, but that reintroduced\n  some performance issues.)\n- Makes runtime shutdown code more defensive. Clear fields pointing to\n  deallocated objects. Always wait for quiescence AFTER all threads\n  are suspended.\n- Consistently checks for a runtime that\u0027s shutting down or missing\n  after waking up from a futex wait, thus avoiding touching deallocated\n  memory. I believe this was the cause of b/121302864, which PS1\n  managed to aggravate.\n- SleepForever() was a very light sleeper, waking up once a second.\n  Fix that, so the daemon threads we leak on runtime shutdown cost\n  us less.\n- Remove a data race from the \"was the runtime deleted\" logic.\n\nBug: 140590186\nBug: 121302864\nTest: Build and boot AOSP.\nTest: art/test/testrunner/testrunner.py --host -b -t 1932-monitor-events-misc\nTest: art/test/testrunner/testrunner.py --host -b -t 132-daemon-locks-shutdown\nTest: art/test/testrunner/testrunner.py --host -b -t 004-ThreadStress\n\nChange-Id: I6667c61beed2ba68c84cd4c0821fb8e21e188bbc\n"
    },
    {
      "commit": "d56f7d1086b16f32c0771a41a4afb376b5fd3076",
      "tree": "41e048cb90e749ffb7e6496db841d4ca80628b5b",
      "parents": [
        "9965feffb2f55ff1e6dfacd396f65e642c22b799"
      ],
      "author": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Tue Nov 19 06:03:11 2019 +0000"
      },
      "committer": {
        "name": "Orion Hodson",
        "email": "oth@google.com",
        "time": "Tue Nov 19 10:28:55 2019 +0000"
      },
      "message": "Revert \"Add spin loop to mutex, overhaul monitor\"\n\nThis reverts commit 0d508a01106746e0d8865752850f4f03bcce1e01.\n\nReason for revert: Preparing revert, in case the art/ci/host-x86_64-cdex-fast failure recurs.\n\nBug: 140590186\n\nChange-Id: I404b6ee498ff4eda73ec3b8fc4bf8e92efb2705f\n"
    },
    {
      "commit": "0d508a01106746e0d8865752850f4f03bcce1e01",
      "tree": "727e9b6a420c3ff1206e97a9ab0369b9947cd797",
      "parents": [
        "25d536e67fc69e0413298989f1b21b6fdcece682"
      ],
      "author": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Fri Aug 30 16:14:32 2019 -0700"
      },
      "committer": {
        "name": "Hans Boehm",
        "email": "hboehm@google.com",
        "time": "Mon Nov 18 18:06:50 2019 +0000"
      },
      "message": "Add spin loop to mutex, overhaul monitor\n\nSince Linux context switch overhead is typically larger than a\nmicrosecond, this may greatly reduce the overhead of waiting for a\nmutex that is only briefly held by another thread. Rather than going\nto sleep and having to be woken back up again, at a cost of several\nmicroseconds, we just spin, hopefully for much less than microsecond,\nuntil the mutex becomes available. It does waste some CPU cycles\nwhen spinning fails, either because the lock is held too long, or\nwe are being scheduled against the thread holding the lock. But we\nexpect those to be unlikely.\n\nWe test the lock only a few times, with pauses in between. It\u0027s\nunclear that\u0027s beneficial; we should perhaps just loop reading\nthe variable. In general, this needs further tuning.\n\nAdd a test that mutual exclusion works, which can also be run as\nlock microbenchmark.\n\nThe old monitor implementation did not benefit much from this, because\nit used mutex only as a low-level lock to protect the monitor data\nstructure. Instead use monitor_lock_ as the actual lock providing\nmutual exclusion for the monitor, i.e. hold onto it while the monitor\nis fatlocked.  Among other things, this requires that the monitor_lock_\nalways be acquired by, or explicitly on behalf of, the thread holding\nthe monitor.\n\nThis in turn makes it really hard to deflate a monitor held by another\nthread. Just stop doing that, since it was unclear whether that\u0027s\nactually beneficial.\n\nThe main advantages of the monitor change are:\n- Half the number of mutex acquisitions.\n- Easier to effectively spin.\n- No possibility of blocking while trying to release a monitor.\n\nNo longer compute owner method and dex pc values on monitor entry\nunless we\u0027re tracing. This was expensive and increased lock hold times\nsufficiently that it often made spinning ineffective.\n\nHave mutex acquisition call futex wait in a loop between updating\nwaiter count. The old way resulted in extra futex wakeups in highly\ncontended situations.\n\nConditionally disable frame size warning for Heap::PreZygoteFork().\nOtherwise the platform doesn\u0027t build with ART_USE_FUTEXES \u003d 0, which\nwe needed for testing.\n\nBased on the new test, this appears to get us about a decimal order\nof magnitude in inflated contended locking performance. Single-threaded\nor scalable applications (i.e. most) should be unaffected. But it should\nprevent applications that do encounter contention from \"falling off a\ncliff\", or at least greatly reduce the height of the cliff. And it\nshould make performance more repeatable by making it less dependent on\nwhether a monitor happens to get inflated.\n\nBug: 111835365\nBug: 140590186\nTest: Successfully built and ran monitor tests. Boots AOSP.\nTest: Build platform with ART_USE_FUTEXES \u003d 0.\nTest: Check contention messages in log after booting AOSP.\nTest: Check systrace output while partially running new test.\n\nChange-Id: Iff7457fff59efcb24e25d35a4ef71b67b8a9082a\n"
    },
    {
      "commit": "f52d92fce224c86491d9b0fd6fca805564119426",
      "tree": "fbf38f272a980e965627918d9dc6bbb536395c00",
      "parents": [
        "e660f7232a19a2c173f562b8e0987755a78ee298"
      ],
      "author": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Fri Mar 29 12:33:02 2019 +0000"
      },
      "committer": {
        "name": "Vladimir Marko",
        "email": "vmarko@google.com",
        "time": "Mon Apr 01 09:37:59 2019 +0000"
      },
      "message": "ObjPtr\u003c\u003e-ify Monitor/-Pool.\n\nTest: m test-art-host-gtest\nTest: testrunner.py --host\nBug: 31113334\nChange-Id: I2d2ebc5ef56e73e5678e0cfcd84c479611dfcca8\n"
    }
  ]
}