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

Aleksey Shipilev aleksey.shipilev at gmail.com
Sat Jun 9 09:53:31 EDT 2012


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.



More information about the Concurrency-interest mailing list