Lines Matching refs:that

6 thread stacks, the garbage collector needs to ensure that Java data processed
8 should not hold references to the heap that are invisible to the garbage
9 collector. And they should not be modifying the data that is visible to the
17 implementation that also provides additional facilities, such as the ability
18 to exclude only a single thread, so that we can specifically examine its heap
34 cooperation, and the thread is not runnable, it is assured that the mutator is
41 ensure that such code, which does not execute "suspend points", and can thus not
47 Although we say that a thread is "suspended" when it is not running Java code,
48 it may in fact still be running native code and touching data structures that
53 mutex. The monitor code must be quite careful to ensure that this does not cause
68 pending suspension requests that slid in just before it changed state.
84 rules of our normal static thread-safety analysis. Thus a function that is
90 differently. It is acquired explicitly by clients that need to hold it
121 that runs a checkpoint function on behalf of each thread, either by using
122 `RequestCheckpoint()` to run it inside a running thread, or by ensuring that a
130 ensures that no thread is still executing Java code inside the same
138 `Resume()` or `ResumeAll()`. The `Suspend...` calls guarantee that the target
159 This ensures that code that uses purely mutexes and threads state changes cannot
163 lock: A thread that is waiting for a lock before it can respond to the request
169 Running a checkpoint in a thread requires suspending that thread for the
171 while that thread is blocked from executing Java code. In the former case, the
174 `kPostMutatorTopLockLevel`. But that is not sufficient.
186 Waiting for something that may depend on the GC, while holding the mutator lock,
192 and these are specific instances of that general problem.
195 low-level locks held. But such code must somehow ensure that such waits
204 the GC. Non-GC checkpoint or suspend requests that target a thread waiting on
220 processing, after acquiring `reference_processor_lock_`.  This means that empty
222 operation that involves a weak reference access, while nonempty checkpoints do.
225 Under unusual conditions, the GC can run on any thread. This means that when
232 Thus we ensure that the GC, together with anything else that can block GCs,
234 ensuring that it always appears to be in a suspended thread state. Since we
242 Thread suspension is initiated by a registered thread, except that, for testing
245 `SuspendThreadBy...()` requests to that effect.
274 inside `SuspendAllInternal()`. This also ensures that the barrier cannot be
277 This relies on the fact that the two stores in the two threads to the state and
283 and `SuspendThreadBy...()`.  The former relies on the fact that only one such
285 active suspend barriers for each target thread, relying on the fact that each
297 a suspend request from a registered thread that is also being asked to suspend
298 (i.e. the suspend count is nonzero).  Instead the requestor waits for that
299 condition to change.  This means that we cannot create a cycle in which each
304 For `SuspendAll()`, we enforce a requirement that at most one `SuspendAll()`
313     by setting this to null, triggering a `SIGSEGV`, causing that thread to
316     that the actual checkpoint function value is set, along with the flag, while
317     holding `suspend_count_lock_`. If the target thread notices that a