Page MenuHomePhabricator

Avoid querying thread stop info if the thread hasn't been running
AbandonedPublic

Authored by labath on Jun 18 2015, 2:42 PM.

Details

Reviewers
clayborg
jingham
Summary

A step over operation on a single thread typically consists of several
start-stop cycles (stepping over breakpoints, etc.). Currently, LLDB queries
the debug server for thread stop info of all threads after each stop, even
though the the other threads have not been running (and hence, their stop info
should remain the same). This introduces significant delay if the application
has many threads (e.g. a typical android application has about 20 threads,
which results in about 80 redundant packets for each step operation). This
commit makes LLDB reuse the stop reason from the previous stop if the thread
hasn't been running, thereby reducing the stepping latency.

Diff Detail

Event Timeline

labath updated this revision to Diff 27963.Jun 18 2015, 2:42 PM
labath retitled this revision from to Avoid querying thread stop info if the thread hasn't been running.
labath updated this object.
labath edited the test plan for this revision. (Show Details)
labath added reviewers: jingham, clayborg.
labath added subscribers: vharron, Unknown Object (MLST).
jingham edited edge metadata.Jun 18 2015, 3:11 PM

I thought about this for much the same reason just a little while ago. Turns out OS X, it is possible for us to stop a process, and fetch all the exceptions, but have some thread exception that wasn't quite ready to be delivered to that thread. The next time you let the task run, that exception will get delivered to the thread even though it is suspended. So it isn't safe to assume that just because WE suspended a thread, it won't have an interesting stop reason, and we had to think of another way to get around this.

Our alternate was to add a "get all thread stop reasons" packet to our extended remote protocol so once you get the stop reply packet you can turn around and get all the remaining stop reasons in one blow.

That seems to me a safer way of getting pretty much the same acceleration.

Jim

labath abandoned this revision.Jun 18 2015, 4:53 PM

I thought about this for much the same reason just a little while ago. Turns out OS X, it is possible for us to stop a process, and fetch all the exceptions, but have some thread exception that wasn't quite ready to be delivered to that thread. The next time you let the task run, that exception will get delivered to the thread even though it is suspended. So it isn't safe to assume that just because WE suspended a thread, it won't have an interesting stop reason, and we had to think of another way to get around this.

That is interesting. As far as I know such a thing cannot happen on linux, but I was wondering if the same is true for other platforms. I will abandon this change then.

Our alternate was to add a "get all thread stop reasons" packet to our extended remote protocol so once you get the stop reply packet you can turn around and get all the remaining stop reasons in one blow.

That was our line of reasoning as well. Thanks for the heads up. I will wait for the change to land.

cheers,
pl

clayborg edited edge metadata.Jun 22 2015, 10:23 AM

Feel free to use this but enable it only for specific triples where you know this is a valid approach. Try using the target's architecture and if it is android or linux OS, then enable this feature.