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
117 that runs a checkpoint function on behalf of each thread, either by using
118 `RequestCheckpoint()` to run it inside a running thread, or by ensuring that a
126 ensures that no thread is still executing Java code inside the same
134 `Resume()` or `ResumeAll()`. The `Suspend...` calls guarantee that the target
155 This ensures that code that uses purely mutexes and threads state changes cannot
159 lock: A thread that is waiting for a lock before it can respond to the request
165 Running a checkpoint in a thread requires suspending that thread for the
167 while that thread is blocked from executing Java code. In the former case, the
170 `kPostMutatorTopLockLevel`. But that is not sufficient.
182 Waiting for something that may depend on the GC, while holding the mutator lock,
188 and these are specific instances of that general problem.
191 low-level locks held. But such code must somehow ensure that such waits
200 the GC. Non-GC checkpoint or suspend requests that target a thread waiting on
216 processing, after acquiring `reference_processor_lock_`.  This means that empty
218 operation that involves a weak reference access, while nonempty checkpoints do.
224 null, triggering a `SIGSEGV`, causing that thread to check for GC cooperation
226 request suspension or a checkpoint. Note that the actual checkpoint function
228 target thread notices that a checkpoint is requested, it then acquires