Home | History | Annotate | Download | only in vm

Lines Matching full:suspend

74 expected to suspend themselves, using a "safe point" mechanism.  We check
75 for a suspend request at certain points in the main interpreter loop,
77 Certain debugger events may inspire threads to self-suspend.
89 thread. The debugger may suspend or resume individual threads, while the
90 GC always suspends all threads. Each thread has a "suspend count" that
91 is incremented on suspend requests and decremented on resume requests.
103 Because threads suspend themselves while interpreting code or when native
118 The debugger may choose to suspend or resume a single thread, which can
123 the thread's suspend count and sending a broadcast signal to the condition
146 The trouble with using signals to suspend threads is that it means a thread
152 The thread must move to a non-blocked state (and self-suspend) after
169 operations and self-suspend. For this to work, the VM must:
180 resources in the GC or debugger (#1) or waiting for threads to suspend
203 handler just returns without doing anything (the "suspend level"
205 if the "suspend level" is nonzero, we go to sleep.
331 * Grab the suspend count global lock.
337 * we have to check for a pending suspend, which results in grabbing
347 * Release the suspend count global lock.
357 * This is held while "suspend all" is trying to make everybody stop. If
363 * the lock. Nobody can suspend all threads without holding the thread list
368 * are required to grab the thread list lock before the thread suspend
371 * TODO: consider checking for suspend after acquiring the lock, and
440 * Grab the "thread suspend" lock. This is required to prevent the
443 * If we fail to get the lock, somebody else is trying to suspend all
464 * thread suspend lock. (We release before the broadcast,
467 * Could be we hit the window as a suspend was started,
468 * and the lock has been grabbed but the suspend counts
479 ALOGI("threadid=%d ODD: want thread-suspend lock (%s:%s),"
480 " it's held, no suspend pending",
491 ALOGE("threadid=%d: couldn't get thread-suspend lock (%s:%s),"
504 * Release the "thread suspend" lock.
517 * shuts down, so we really need to kill or suspend them. (If we want
521 * Waiting for the thread to suspend may be unwise at this point, but
554 /* should never happen; suspend it with the rest */
577 * and that function *doesn't* check for pending suspend after
579 * and see the pending suspend before we continue here.
582 * (The alternative is to have dvmLockThreadList check for suspend
1341 * So, we change our own status to VMWAIT, and self-suspend if
1350 * we could create the thread while the VM is trying to suspend all
1351 * threads. The suspend-count won't be nonzero for the new thread,
1364 * + thread list locked; suspend counts updated; thread list unlocked
1365 * + loop waiting for all runnable threads to suspend
1372 * - change our state back to THREAD_RUNNING; GC causes us to suspend
1387 * suspended, and try to decrement the child's thread suspend count to -1.
1397 * was caused by a suspend-all. If the parent was being asked to
1398 * suspend singly by the debugger, the child should not inherit the value.
1400 * We could also have a global "new thread suspend count" that gets
1403 * suspend-all.
1438 * comes with a suspend-pending check.
1484 * suspend pending, this will happen immediately. When it completes,
1489 * suspend-all is also interested in. If we get unlucky, the parent could
1491 * signaled, and suspend-all will grab the thread list lock and then
1492 * wait for us to suspend. We'll be in the tail end of pthread_cond_wait
1507 * in progress this call will suspend us.
1513 * us to suspend ourselves (and others). The thread state may change
1837 * suspend count won't reflect the fact that we should be suspended.
2075 * threads to suspend.
2174 * Suspend a single thread. Do not use to suspend yourself.
2182 * (We'd need to grab it here anyway to avoid clashing with a suspend-all.)
2193 LOG_THREAD("threadid=%d: suspend++, now=%d",
2201 * Reduce the suspend count of a thread. If it hits zero, tell it to
2205 * might have been suspended singly or as part of a suspend-all operation.
2209 * (We'd need to grab it here anyway to avoid clashing with a suspend-all.)
2225 LOG_THREAD("threadid=%d: suspend--, now=%d",
2236 * Suspend yourself, as a result of debugger activity.
2242 /* debugger thread must not suspend itself due to debugger activity! */
2251 * to ensure that we're the only one fiddling with the suspend count
2258 * Suspend ourselves.
2267 * suspend count lock.
2285 * just long enough to try to grab the thread-suspend lock).
2403 * It can either suspend itself or go into a non-running state such as
2417 * waiting for each other to suspend. In normal use this is part of a
2418 * suspend-all, which implies that the suspend-all lock is held, or as
2421 * getThreadStackTrace is implemented as suspend-snapshot-resume.)
2423 * TODO: track basic stats about time required to suspend VM.
2479 ALOGW("threadid=%d: spin on suspend #%d threadid=%d (pcf=%d)",
2494 ALOGE("Fatal spin-on-suspend, dumping threads");
2510 ALOGW("threadid=%d: spin on suspend resolved in %lld msec",
2522 * Suspend all threads except the current one. This is used by the GC,
2523 * the debugger, and by any thread that hits a "suspend all threads"
2526 * If thread N hits a "suspend all threads" breakpoint, we don't want it
2527 * to suspend the JDWP thread. For the GC, we do, because the debugger can
2531 * This can be called when a global suspend has already happened, due to
2536 * lock and suspend lock here (and we're not using recursive threads), and
2537 * we might have to self-suspend if somebody else beats us here.
2551 * Start by grabbing the thread suspend lock. If we can't get it, most
2552 * likely somebody else is in the process of performing a suspend or
2553 * resume, so lockThreadSuspend() will cause us to self-suspend.
2563 * suspend-all happened, and then decided to do its own suspend-all.
2570 * Increment everybody's suspend count (except our own).
2579 /* debugger events don't suspend JDWP thread */
2601 * so if another thread is fiddling with its suspend count (perhaps
2609 /* debugger events don't suspend JDWP thread */
2614 /* wait for the other thread to see the pending suspend */
2631 * The "why" must match with the previous suspend.
2638 lockThreadSuspend("res-all", why); /* one suspend/resume at a time */
2642 * Decrement the suspend counts for all threads. No need for atomic
2652 /* debugger events don't suspend JDWP thread */
2673 * In some ways it makes sense to continue to hold the thread-suspend
2682 * thread-suspend lock.
2686 * is told to suspend, the clock resets; but since the VM is still
2687 * theoretically mid-resume, there's no suspend pending. If, for
2693 * suspend can't actually start until the broadcast completes and
2694 * returns, because we're holding the thread-suspend-count lock, but the
2698 * the thread-suspend lock and grab the thread-suspend-count lock.
2700 * suspend counts, but this is expected and they'll all just fall
2701 * right back to sleep. It's probably safe to grab the suspend-count
2702 * lock before releasing thread-suspend, since we're still following
2737 * Decrement the suspend counts for all threads. No need for atomic
2747 /* debugger events don't suspend JDWP thread */
2794 * (2) Pending suspend. status is RUNNING, suspendCount is nonzero.
2810 * to suspend itself after sending an event to the debugger.
2812 * Threads that encounter "suspend all" events work as well -- the thread
2816 * get here just before the to-be-waited-for-thread issues a "suspend all".
2840 * Check to see if we need to suspend ourselves. If so, go to sleep on
2862 ATRACE_BEGIN("DVM Suspend");
2885 * Check to see if a suspend is pending. If so, suspend the current
2931 * check suspend count (== 0)
2933 * grab suspend-count lock
2934 * increment all suspend counts
2935 * release suspend-count lock
2941 * We can correct this by grabbing the suspend-count lock and
2942 * performing both of our operations (check suspend count, set
2948 * that the suspend count is nonzero, we switch to SUSPENDED.
2961 * We can also solve this by combining the "status" and "suspend
2964 * op on all transitions and all suspend count updates (also, all