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

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Tue Jun 26 00:09:18 EDT 2012


*"Static and member empty methods will be inlined by JIT optimization and
hence no instructions will be added to the optimized code. "*

Methods like 'buildQueues'  that the new AspectJ compilers use is a empty
method.

@Aspect
public class ForkJoinProjector {
  @Pointcut( "execution ( int
java.util.concurrent.ForkJoinPool.registerWorker(java.util.concurrent.
 ForkJoinWorkerThread)) &&" +
                   " args(thread) &&" +
                   " target(pool)" )

    *public void buildQueues( ForkJoinWorkerThread thread,
                      ForkJoinPool pool){}
*
    @After("buildQueues( thread,pool)")
    public void build( ForkJoinWorkerThread thread,
                                   ForkJoinPool pool ) {
     System.out.println( "ID " + thread.getId() + " Name " +
thread.getName() );
    }

}

Thanks.


On Mon, Jun 25, 2012 at 11:48 PM, Aleksey Shipilev <
aleksey.shipilev at gmail.com> wrote:

> 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.
>
> -Aleksey.
>
> 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
> >
>
> _______________________________________________
> 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/20120626/034a0f99/attachment.html>


More information about the Concurrency-interest mailing list