| 4cd121ef0cb35fced70c7d9de378277be7a727d9 |
|
08-Jan-2013 |
Elliott Hughes <enh@google.com> |
Implement the Thread.sleep native method.
This makes returning TS_SLEEPING from JDWP simple and cheap, and
makes the stack dumps for sleeping threads more easily understood
by app developers (because there's no Object.wait magic going, and
the thread state is "Sleeping" rather than "TimedWaiting").
Also make Object.wait() a native method in its own right, so every call into
Monitor::Wait can explicitly pass the most appropriate ThreadState: kSleeping,
kWaiting, or kTimedWaiting.
Also add Thread.sleep and Object.wait(long, int) calls to the ThreadStress test.
Change-Id: I49adb45dbcd669eba7cf3def45e6cbfc461a3254
|
| cd74c4b3a6893c876c6e03fd99a1264249653d80 |
|
23-Jan-2012 |
Brian Carlstrom <bdc@google.com> |
Fix thread hang
- Primary problem was ScopedThreadListLock was releasing heap lock in constructor instead of destructor
- Secondary problem was ScopedThreadListLock should not be used with Mutex::Wait
- Added Thread.getStackTrace case to ThreadStress that reproduces YouTube problem
- Added Mutex::GetDepth and related methods that were useful in diagnoising this issue
Change-Id: I1bdc7245e9b411378b98f4dcf498ad66eb96366d
|
| 831afe4c2334f3d96df39538023f122101c89384 |
|
16-Dec-2011 |
Elliott Hughes <enh@google.com> |
Improve the ThreadStress test to send SIGQUIT, and fix the bug that finds.
I'd heard complaints of a system_server deadlock on crespo, but wasn't seeing
it on mysid. I did see it soon after trying to use crespo, but system_server
has way too many threads and adb is too damn unreliable for me to effectively
debug that. This improves ThreadStress so we exercise that path lots, and
catch the deadlock relatively quickly with relatively few threads.
The fix is explained in a code comment that's larger than the fix.
Change-Id: I593bc94cf1239065a604703568420986a03ce628
|
| 4514d3c0e69a49f5dbe19138330a2bb2aee36d63 |
|
22-Oct-2011 |
Brian Carlstrom <bdc@google.com> |
Fixes for ThreadStress test
- Fix deadlock when ThreadGroup.remove(Thread) was run with
thread_list_lock_ but needed to GC to allocate an iterator
- Fix ~MonitorList to clean ownership of any locks that might be held
by JNI or daemon threads on shutdown.
Change-Id: I95e23c3b7c745f6a8387789949f3ec849458a27d
|
| 7c6deaa3382f1f4fb0f591af206f03045c6e9004 |
|
21-Oct-2011 |
Brian Carlstrom <bdc@google.com> |
Add ThreadStress test to try and exercise corner cases
Change-Id: I8d151e9ba935b8c76406483c6c276cc26896aabf
|