[concurrency-interest] Volatile/final and the JIT

Brian Goetz brian at briangoetz.com
Sun May 10 17:36:38 EDT 2009


AOP works at the bytecode level, so if you were weaving in aspects, the code 
that HotSpot would see would be the post-woven code.

Adding generic tracing aspects has all the same distortive effects as 
injecting the tracing into the source code; adding more code into the source 
can definitely distort how HotSpot will JIT the code, so the AOP version could 
do the same.

Markus Jevring wrote:
> 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
> 


More information about the Concurrency-interest mailing list