opaque function call and its side effects

210 views
Skip to first unread message

Vijay

unread,
Feb 25, 2015, 11:26:13 AM2/25/15
to mechanica...@googlegroups.com
I have not seen much discussion/literature on "opaque" functions in java in terms of compiler and their side effect on performance. I am guessing making methods small and in-lining friendly would be a start.

Vitaly Davidovich

unread,
Feb 25, 2015, 11:32:22 AM2/25/15
to mechanica...@googlegroups.com
Martin linked a good blog on method dispatch a few days ago: https://groups.google.com/forum/#!topic/mechanical-sympathy/IBpsIUgvIqA


On Wed, Feb 25, 2015 at 11:26 AM, Vijay <dhan...@gmail.com> wrote:
I have not seen much discussion/literature on "opaque" functions in java in terms of compiler and their side effect on performance. I am guessing making methods small and in-lining friendly would be a start.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Thompson

unread,
Feb 25, 2015, 11:41:21 AM2/25/15
to mechanica...@googlegroups.com
"Inlining is THE enabling optimisation..." was a great quote from Cliff Click that stuck with me from years ago. Cliff pointed out that without inlining then most other optimisations cannot be applied. If a method is not inlined then it is opaque to the caller.

It is worth running JitWatch to see what has been optimised in your code, and more importantly what has not.

https://github.com/AdoptOpenJDK/jitwatch/

Vijayant Dhankhar

unread,
Feb 25, 2015, 1:30:25 PM2/25/15
to mechanica...@googlegroups.com
Thanks Martin for the link, I think I am right in saying that compiler would treat opaque function call as if it contains a full memory barrier and all reordering optimizations would not happen through the call site. Positioning of an opaque function call  could make for some performance improvements.

Martin Thompson

unread,
Feb 25, 2015, 1:42:31 PM2/25/15
to mechanica...@googlegroups.com
C provides software ordering constraints around function calls. I don't think I've seen anything in the Java Memory Model regarding function/method calls and ordering (other than JNI).

All the ordering the method could provide would be to the compiler and not to the hardware. Therefore not a full fence. This does not feel like a very useful or predictable optimisation to me. Better to stick with synchronising actions, ordered writes, and the fences as provided in Unsafe.

I'd be tempted to refer this approach to a tweet from the other day. :-) No harm in thinking outside the box as a little experiment in understanding but I would not do such things in production code.



--

Gil Tene

unread,
Feb 26, 2015, 2:36:49 AM2/26/15
to mechanica...@googlegroups.com
To be more specific about what Martin says below under "...does not feel like a very useful or predictable optimisation": In Java for example, method call sites provide zero ordering semantics with the surrounding code. A compiler *may* inline any method (even truly polymorphic ones) at any call site. And if a compiler does happen to inline a method it may reorder the operations in that methods with operations that occur in the caller both before and after the call site. And along with that reordering, operations in the caller that occur before and after the call site may be reordered against each other as well.

So:

doA
f()
doB

does not imply anything about the execution order of otherwise unrelated operations doA and doB.

e.g. if f() was basically "doC", the above may be legitimately reordered to be:

doC
doB
doA

On the other hand, *if* a compiler fails to inline a method, and *if* it has also no other useful knowledge that restricts what that method might end up doing (the "opaque" quality in the subject), then since the method *may* contain operations that force ordering, the compiler will generally lose the ability to reorder caller operations across the method call site. But (in Java at least) there is no way to semantically force that "loss of ability" to happen, so it cannot be relied on...

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

Vijayant Dhankhar

unread,
Feb 26, 2015, 8:57:10 AM2/26/15
to mechanica...@googlegroups.com
Thanks Gil and Martin.. I was not meaning to exploit this as a substitute for correctness but merely trying to understand the behavior.
Reply all
Reply to author
Forward
0 new messages