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.<br>
<br>Having the JIT to respect program semantics I believe it can&#39;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 paths.<br>
<br>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.<br>
<br>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 ?<br>
<br>class Process {<br>    void process() {<br>        Foo foo = new Foo();<br>        foo.setX(); foo.getX().add();<br>        /* do other stuff not concerning foo */<br>        fooHandler.record(foo);<br>    }<br>}<br><br>
class FooHandler {<br>    void record() {<br>        if (flagOn) <br>            doSomething(foo);<br>    }<br>}<br><br>Quite curious about the subject, do you recommend some pointers about the JIT capabilities and optimizations techniques ?<br>
<br>Regards,<br>Pierre.<br><br><div class="gmail_quote">2009/5/8 Markus Jevring <span dir="ltr">&lt;<a href="mailto:markus.jevring@petercam.be">markus.jevring@petercam.be</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In your last case, where you say that HotSpot will have multiple<br>
potential paths to take (one of which examines the nullity higher up in<br>
the tree), would the method(s) actually get invoked in this path, or<br>
would it just be pruned based on this condition?<br>
For example, if we have an aspect oriented solution that relies on<br>
methods getting invoked, and these methods get pruned, then these<br>
methods would never get called, and the aspect that is triggered only<br>
when the methods get called would never run.<br>
Or could it be that, since some languages (aspectj, for instance)<br>
&quot;weaves&quot; code in at compile time, there *is* actually a reason to take<br>
an execution path that would have otherwised gotten pruned?<br>
<br>
The reason I ask is: if we have some generic tracing aspect that logs<br>
method invocations, would the very presence of this aspect, whether it<br>
does anything or not (logging enabled/disabled) prevent HotSpot from<br>
pruning the path in question, leading to potentially lower performance<br>
by forcing HotSpot&#39;s hand by disallowing certain optimizations that<br>
might otherwise be done?<br>
<br>
Granted, I don&#39;t see aspect oriented programming as something<br>
necessarily performant, but I thought I&#39;d ask.<br>
<font color="#888888"><br>
Markus Jevring<br>
</font><div><div></div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a><br>
[mailto:<a href="mailto:concurrency-interest-bounces@cs.oswego.edu">concurrency-interest-bounces@cs.oswego.edu</a>] On Behalf Of Brian<br>
Goetz<br>
Sent: jeudi 7 mai 2009 4:38<br>
To: Christian Vest Hansen<br>
Cc: <a href="mailto:concurrency-interest@cs.oswego.edu">concurrency-interest@cs.oswego.edu</a><br>
Subject: Re: [concurrency-interest] Volatile/final and the JIT<br>
<br>
&gt; Different instances of this class may have different values assigned<br>
&gt; to the statistics field, but the code itself is static and, I would<br>
&gt; assume, optimized as such.<br>
<br>
This is not true.  There&#39;s nothing that says the JIT need only compile<br>
one<br>
version of a given method.  HotSpot will readily clone code where it can<br>
spot<br>
a slow/fast path, even based on deep inlining.  For example:<br>
<br>
foo(Moo x) {<br>
   goo(x);<br>
}<br>
<br>
goo(Moo x) {<br>
   if (x != null) { something expensive }<br>
}<br>
<br>
Here, calls to foo() may will be inlined (or inlined-cached), and in the<br>
<br>
branch where it is inlined, it can pull the null check all the way out<br>
to the<br>
caller, and have two completely different paths based on a condition<br>
that is<br>
way far down the tree.<br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br>