| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit ead89ef62768faa06fedd279b86bccbed1464673.
PS1 is identical to Revert^2.
This fixes a shutdown issue caused by prematurely hanging when we
block while trying to acquire system mutexes during shutdown.
Only refuse to wake up after shutdown is well under way.
Bug: 140590186
Bug: 121302864
Test: Build and boot AOSP.
Test: art/test/testrunner/testrunner.py --host -b -t 1932-monitor-events-misc
Test: art/test/testrunner/testrunner.py --host -b -t 004-ThreadStress
Test: art/test/testrunner/testrunner.py --host -b -t 132-daemon-locks-shutdown
Test: 132-daemon-locks-shutdown repeated with increased thread counts and multiple
concurrent tests.
Change-Id: Ic19d32652a2a05c1ca843b3e9c6e29e6770262da
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3d52abe40e619497b1b59cfce92c74b5a417add5.
Reason for revert: Causes asan build timeout; Apparently the runtime
goes away while we're holding a system mutex. We now sleep forever
without releasing it.
Bug: 140590186
Bug: 121302864
Change-Id: I9e4dcaf820815c751aa803473809955451988ebd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d56f7d1086b16f32c0771a41a4afb376b5fd3076.
Reason for revert: PS2 fixes the problems I identified.
PS1 is straight revert^2 of, and thus identical to aosp/1111800.
PS2 in addition:
- Reduces the size of the test, when not modified to run as benchmark.
- Disables the test in slow-running configurations, which timed out.
- Stops using the mutex recursion count, and instead reintroduces
one at the monitor level. The plan is to eliminate the one in mutex
in a future CL.
- Avoids modifying various monitor fields in suspended state.
MonitorInfo, deflation, etc., may look at the state of a suspended
thread and expect not to race. I don't think the original code had
this completely correct either, but PS1 made it worse.
- Documents some aspects of the code that confused me at times.
- Avoids dereferencing the monitor owner Thread* unless it holds the
thread list lock, and thus knows that the thread won't go away.
- Stores a Thread* instead of a thread_id with the monitor owner method
and dex pc information used for debugging. This is required to avoid
extra thread list lock acquisitions, since we need to dereference the
owner to get the thread id.
- Makes the thread list Contains method public, again in order to
support the above. (This ignores C/C++ restrictions on dangling
pointer use. We already rely on violating those elsewhere, and
the committees are trying to get their story straight about this.)
- Causes the spin loop to give up immediately if the process is
shutting down. This gets us to an actual idle state sooner in that
case, and should hopefully mitigate the shutdown issues somewhat.
(We tried not spinnning in "suspended" state, but that reintroduced
some performance issues.)
- Makes runtime shutdown code more defensive. Clear fields pointing to
deallocated objects. Always wait for quiescence AFTER all threads
are suspended.
- Consistently checks for a runtime that's shutting down or missing
after waking up from a futex wait, thus avoiding touching deallocated
memory. I believe this was the cause of b/121302864, which PS1
managed to aggravate.
- SleepForever() was a very light sleeper, waking up once a second.
Fix that, so the daemon threads we leak on runtime shutdown cost
us less.
- Remove a data race from the "was the runtime deleted" logic.
Bug: 140590186
Bug: 121302864
Test: Build and boot AOSP.
Test: art/test/testrunner/testrunner.py --host -b -t 1932-monitor-events-misc
Test: art/test/testrunner/testrunner.py --host -b -t 132-daemon-locks-shutdown
Test: art/test/testrunner/testrunner.py --host -b -t 004-ThreadStress
Change-Id: I6667c61beed2ba68c84cd4c0821fb8e21e188bbc
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 0d508a01106746e0d8865752850f4f03bcce1e01.
Reason for revert: Preparing revert, in case the art/ci/host-x86_64-cdex-fast failure recurs.
Bug: 140590186
Change-Id: I404b6ee498ff4eda73ec3b8fc4bf8e92efb2705f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Linux context switch overhead is typically larger than a
microsecond, this may greatly reduce the overhead of waiting for a
mutex that is only briefly held by another thread. Rather than going
to sleep and having to be woken back up again, at a cost of several
microseconds, we just spin, hopefully for much less than microsecond,
until the mutex becomes available. It does waste some CPU cycles
when spinning fails, either because the lock is held too long, or
we are being scheduled against the thread holding the lock. But we
expect those to be unlikely.
We test the lock only a few times, with pauses in between. It's
unclear that's beneficial; we should perhaps just loop reading
the variable. In general, this needs further tuning.
Add a test that mutual exclusion works, which can also be run as
lock microbenchmark.
The old monitor implementation did not benefit much from this, because
it used mutex only as a low-level lock to protect the monitor data
structure. Instead use monitor_lock_ as the actual lock providing
mutual exclusion for the monitor, i.e. hold onto it while the monitor
is fatlocked. Among other things, this requires that the monitor_lock_
always be acquired by, or explicitly on behalf of, the thread holding
the monitor.
This in turn makes it really hard to deflate a monitor held by another
thread. Just stop doing that, since it was unclear whether that's
actually beneficial.
The main advantages of the monitor change are:
- Half the number of mutex acquisitions.
- Easier to effectively spin.
- No possibility of blocking while trying to release a monitor.
No longer compute owner method and dex pc values on monitor entry
unless we're tracing. This was expensive and increased lock hold times
sufficiently that it often made spinning ineffective.
Have mutex acquisition call futex wait in a loop between updating
waiter count. The old way resulted in extra futex wakeups in highly
contended situations.
Conditionally disable frame size warning for Heap::PreZygoteFork().
Otherwise the platform doesn't build with ART_USE_FUTEXES = 0, which
we needed for testing.
Based on the new test, this appears to get us about a decimal order
of magnitude in inflated contended locking performance. Single-threaded
or scalable applications (i.e. most) should be unaffected. But it should
prevent applications that do encounter contention from "falling off a
cliff", or at least greatly reduce the height of the cliff. And it
should make performance more repeatable by making it less dependent on
whether a monitor happens to get inflated.
Bug: 111835365
Bug: 140590186
Test: Successfully built and ran monitor tests. Boots AOSP.
Test: Build platform with ART_USE_FUTEXES = 0.
Test: Check contention messages in log after booting AOSP.
Test: Check systrace output while partially running new test.
Change-Id: Iff7457fff59efcb24e25d35a4ef71b67b8a9082a
|
|
|
Test: m test-art-host-gtest
Test: testrunner.py --host
Bug: 31113334
Change-Id: I2d2ebc5ef56e73e5678e0cfcd84c479611dfcca8
|
