[concurrency-interest] Fork/Join traces: instrumentation and rendering
mr.chrisvest at gmail.com
Sat Jun 9 13:28:13 EDT 2012
I think it's an interesting way to visualise how the FJP crunches a task.
As in your example, it can help show if the tasks are badly balanced,
though I don't know how big a problem that is in practice. Github
repositories are a pretty cheap commodity, so I don't think this would be
contaminating it :)
One thing it makes me wonder is, if the FJP is executing some slow tasks
and a number of joiners are waiting on them, and then another task is
submitted, then there will be fewer threads to handle the new work?
On 9 June 2012 15:53, Aleksey Shipilev <aleksey.shipilev at gmail.com> wrote:
> FYI, there is an updated version , which piggybacks heavily on
> WorkQueue mechanics to avoid serial bottlenecks when writing the
> trace, and Unsafe to provide binary representation for traces without
> resorting to string ops. It is somewhat 20x faster on my laptop with
> tracing enabled than previous one. This only visible when there are
> lots of FJP events, which is always the case when tasks are tiny. With
> modest task sizes, the overhead of tracing is bearable.
>  http://shipilev.net/pub/stuff/fjp-trace/
> On Fri, Jun 8, 2012 at 11:47 PM, Aleksey Shipilev
> <aleksey.shipilev at gmail.com> wrote:
> > Hi everyone,
> > I was crawling through nastly performance problem with FJP and my
> > particular use case. This forced me to do the instrumentation in FJP,
> > and also sketch up some FJP-specific analyzers.
> > While thinking around what to do with that next, I figured it would be
> > to ask if this tool is something community wants/needs, or I can just
> > throw it in the trunk, and leave it there. (Maybe it is not even worth
> > to contaminate GitHub with).
> > The bundle is at http://shipilev.net/pub/stuff/fjp-trace/. See README
> > there. In short, this provides instrumented FJP, which dumps the
> > execution traces, which then can be analyzed, down to fork-join
> > dependencies, steals, parks-unparks, etc.
> > For instance, this is one use case I was chasing:
> > - http://shipilev.net/pub/stuff/fjp-trace/fjp-trace-sample.png
> > - that's a 4x10x2 Nehalem running 8b39-lambda
> > - doing FJP.submit().get(), hence waiting for external task to complete
> > - note that FJP ramps up really quickly, in less than 5ms
> > - two heavily out-balanced tasks are seen as green bars
> > - six joiners are waiting on those tasks to complete
> > - one could also estimate the actual integral parallelism
> > Thoughts?
> > -Aleksey.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest