[concurrency-interest] Fork/Join traces: instrumentation and rendering

Chris Vest 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 [1], 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.
>
> -Aleksey.
>
> [1] 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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120609/ec12c78d/attachment.html>


More information about the Concurrency-interest mailing list