[concurrency-interest] Volatile/final and the JIT

Pierre Fourès pierre.foures at gmail.com
Sat May 9 04:57:27 EDT 2009

While AOP just offers to programmers an other dimension to modularize and
compose their softwares but produces at last regular java (byte)code the JIT
should see it as an other regular sequence of bytecode to optimize.

Having the JIT to respect program semantics I believe it can't prune the
calls to advices. However it could inline them higher up with still passing
the right context to them (which is not magic, just some basic references to
java objects). Thus the JIT would be able to prune away some unnecessary

For the case of code doing nothing and with the facts the JIT being able to
figurate this out for regular java programs and that aspectized programs
becomes regulars java program when weaved, I believe the presence of aspects
would not disallow certain optimizations (like to prune away empty aspect
with the rest of the path). As more code is involved I guess it just make it
harder for the JIT to figure out what it could do or not.

All this makes me wonder about the JIT abilities : In the case of creating
and populating some new instance but not using it later on (some flag went
of) could the JIT optimize away all the path to creating this instance ? Up
to check that no side effects are encountered while invoking foo during its
population ?

class Process {
    void process() {
        Foo foo = new Foo();
        foo.setX(); foo.getX().add();
        /* do other stuff not concerning foo */

class FooHandler {
    void record() {
        if (flagOn)

Quite curious about the subject, do you recommend some pointers about the
JIT capabilities and optimizations techniques ?


2009/5/8 Markus Jevring <markus.jevring at petercam.be>

> In your last case, where you say that HotSpot will have multiple
> potential paths to take (one of which examines the nullity higher up in
> the tree), would the method(s) actually get invoked in this path, or
> would it just be pruned based on this condition?
> For example, if we have an aspect oriented solution that relies on
> methods getting invoked, and these methods get pruned, then these
> methods would never get called, and the aspect that is triggered only
> when the methods get called would never run.
> Or could it be that, since some languages (aspectj, for instance)
> "weaves" code in at compile time, there *is* actually a reason to take
> an execution path that would have otherwised gotten pruned?
> The reason I ask is: if we have some generic tracing aspect that logs
> method invocations, would the very presence of this aspect, whether it
> does anything or not (logging enabled/disabled) prevent HotSpot from
> pruning the path in question, leading to potentially lower performance
> by forcing HotSpot's hand by disallowing certain optimizations that
> might otherwise be done?
> Granted, I don't see aspect oriented programming as something
> necessarily performant, but I thought I'd ask.
> Markus Jevring
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Brian
> Goetz
> Sent: jeudi 7 mai 2009 4:38
> To: Christian Vest Hansen
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Volatile/final and the JIT
> > Different instances of this class may have different values assigned
> > to the statistics field, but the code itself is static and, I would
> > assume, optimized as such.
> This is not true.  There's nothing that says the JIT need only compile
> one
> version of a given method.  HotSpot will readily clone code where it can
> spot
> a slow/fast path, even based on deep inlining.  For example:
> foo(Moo x) {
>   goo(x);
> }
> goo(Moo x) {
>   if (x != null) { something expensive }
> }
> Here, calls to foo() may will be inlined (or inlined-cached), and in the
> branch where it is inlined, it can pull the null check all the way out
> to the
> caller, and have two completely different paths based on a condition
> that is
> way far down the tree.
> _______________________________________________
> 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/20090509/ba899806/attachment-0001.html>

More information about the Concurrency-interest mailing list