Community
Participate
Working Groups
I noticed that the DelayedStackRefreshUpdatePolicy flushes the cached data of the execution context for a suspended event which leads to a stack depth retrieval from the service when computing the delta for the event. This should be avoided for optimal stepping performance. See also Ken's mail on cdt-dev: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg18566.html
Created attachment 166457 [details] Fix This seems to fix it.
Pawel, would you review before I commit? I am not sure about potential side-effects.
The only other side effect that I can think of is that the thread's label and icon will not update until the full stack refresh event. Having this update meant that the thread icon was often flashing between running and suspended states. Eliminating this behavior is actually a positive change though.
(In reply to comment #3) > The only other side effect that I can think of is that the thread's label and > icon will not update until the full stack refresh event. Having this update > meant that the thread icon was often flashing between running and suspended > states. Eliminating this behavior is actually a positive change though. I wonder what triggers the label update of the thread. Is this a result of the EXPAND delta? Related to that, would it make sense to have an update flag to update all properties? This would correlate to the STATE delta. Committed to HEAD.
(In reply to comment #4) > I wonder what triggers the label update of the thread. Is this a result of the > EXPAND delta? The resume event handling? All this really begs for some controlled tests... > Related to that, would it make sense to have an update flag to update all > properties? This would correlate to the STATE delta. Yes! It may even make sense to allow flushing of only select properties, at least that's the only way I can think of to implement bug 310992.
I believe this fix caused Bug 311416 where stack frames are missing. One may have to turn off the "Limit stack frames" option to see the problem.
The fix for this has caused issues, e.g. bug 312817, therefore I backed out the changes. I am marking this invalid, because with the current cache behavior there is no way to relax the flushing rules.
(In reply to comment #7) > The fix for this has caused issues, e.g. bug 312817, therefore I backed out the > changes. > I am marking this invalid, because with the current cache behavior there is no > way to relax the flushing rules. If it's OK with everyone, I'd like to keep this bug opened and try to address it again past 7.0. We'll likely need to extend the cache API to support the optimal optimization ;-), but more importantly we'll need to have a good regression test suite also.
*** cdt cvs genie on behalf of aleherbau *** Bug 310992 - [vm][cache] Unnecessary cache flushing of thread children on suspended event [*] DelayedStackRefreshUpdatePolicy.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/ui/viewmodel/launch/DelayedStackRefreshUpdatePolicy.java?root=Tools_Project&r1=1.2&r2=1.3
