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

Aleksey Shipilev aleksey.shipilev at gmail.com
Mon Jun 25 14:18:00 EDT 2012

It is somewhat different with concurrency code and pessimistic
compilers, and IMO that is why Doug is paranoid about this (not that I
disagree with him). The current code for fjp-trace does the similar
thing: checking static final variable first thing after the
instrumented call. Granted, there is still possible overhead for
calling the virtual method, which smart JITs are able to optimize. At
this point, re-read the first sentence.

I'm not sure if there exists any practical way to guarantee zero
overheads without bringing "smart compiler" argument into the
discussion. Bytecode rewriting is one questionable solution, due to
rather complicated hotpaths in the FJP code. I would like to thing in
this direction without assuming smart compilers.


On Mon, Jun 25, 2012 at 9:46 PM, Mark Thornton <mthornton at optrak.com> wrote:
> On 25/06/12 17:24, Nathan Reynolds wrote:
>  Static final booleans initialized at runtime will *hopefully* cause JIT
> optimization to throw out the check and dead code.  I haven't checked this
> latter point.
> They do in my experience. My tracing code relies on it to give zero cost
> when disabled. I think this also applies to assertions.
> Mark Thornton
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list