http://gwt-code-reviews.appspot.com/1336803/diff/1/3 File dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java (right):
http://gwt-code-reviews.appspot.com/1336803/diff/1/3#newcode592 dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:592: "Cummulative Collection Count", Long.toString(gcMXBean.getCollectionCount())); On 2011/02/03 23:34:27, conroy wrote:
On 2011/02/03 23:12:13, jbrosenberg wrote: > Yes it is a parallel timeline (which represents the gc happening in
a separate
> thread), but in practice this actually produces nice output, with
the GC
events > as separate waterfalls aligned and above the main event they
correspond to.
The > totals do appear to be accurate, but you have to take it for what it
is (e.g.
GC > took 25% of the total time logged). If you want, I can send you
some sample
> generated output, if you would like to sanity check it.
Basically there are a few points in speedtracer land where we binary
search
through data which breaks down with parallel events. If you run a
debug build of
speedtracer on your data, there will be an error message logged if we
detect
that the data isn't ordered as we expect.
Although, I think parallel top level events might be shielded from
most of this. What will get screwed up in speedtracer for top level events coming in out of order or parallel timelines that measure events in separate threads are the summaries, I believe. The app still works, you just can't trust the summary graphs. http://gwt-code-reviews.appspot.com/1336803/diff/3002/4006#newcode313 dev/core/src/com/google/gwt/dev/util/log/speedtracer/SpeedTracerLogger.java:313: * Thread that converts log requests to JSON in the background. I don't understand this calculation. The more time you've spent in the thread up to this point, the farther back the reset goes? http://gwt-code-reviews.appspot.com/1336803/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
