A couple of updates for Android's inclusive language guidance
Based on:
https://source.android.com/setup/contribute/respectful-code
Bug: 161896447
Bug: 161850439
Bug: 161336379
Test: Comment updates, no tests.
Change-Id: I535b0e10b0c4cdb712c17d1fda91461018d5c8f2
diff --git a/runtime/interpreter/mterp/README.txt b/runtime/interpreter/mterp/README.txt
index 54bb634..c550911 100644
--- a/runtime/interpreter/mterp/README.txt
+++ b/runtime/interpreter/mterp/README.txt
@@ -78,4 +78,4 @@
to altHandlerTable. Note that this change is not immediate. What is actually
changed is the value of curHandlerTable - which is part of the interpBreak
structure. Rather than explicitly check for changes, each thread will
-blindly refresh rIBASE at backward branches, exception throws and returns.
+unconditionally refresh rIBASE at backward branches, exception throws and returns.
diff --git a/runtime/monitor.h b/runtime/monitor.h
index 0714da1..c0a0a4f 100644
--- a/runtime/monitor.h
+++ b/runtime/monitor.h
@@ -350,11 +350,11 @@
// - If contention reporting is enabled, we use the lock_owner_request_ field to have the
// contending thread request them. The current owner then sets them when releasing the monitor,
// making them available when the contending thread acquires the monitor.
- // - If both are enabled, we blindly do both. This usually prevents us from switching between
- // reporting the end and beginning of critical sections for contention logging when tracing is
- // enabled. We expect that tracing overhead is normally much higher than for contention
- // logging, so the added cost should be small. It also minimizes glitches when enabling and
- // disabling traces.
+ // - If tracing and contention reporting are enabled, we do both. This usually prevents us from
+ // switching between reporting the end and beginning of critical sections for contention logging
+ // when tracing is enabled. We expect that tracing overhead is normally much higher than for
+ // contention logging, so the added cost should be small. It also minimizes glitches when
+ // enabling and disabling traces.
// We're tolerant of missing information. E.g. when tracing is initially turned on, we may
// not have the lock holder information if the holder acquired the lock with tracing off.
//