0

If you have in Java for example:

void methodA(int i) { ... }

void wrapperMethodArg1() {  methodA(1); }

wrapperMethodArg1();

when you call the second method, will the JVM eventually do two or one method calls?

Sotirios Delimanolis
  • 274,122
  • 60
  • 696
  • 724
gfot
  • 95
  • 2
  • 11
  • obvously 2 its machine – dev2d Feb 18 '15 at 00:01
  • 2
    It will eventually do two or one method calls. – isnot2bad Feb 18 '15 at 00:02
  • The compiler can choose to optimize your code by inlining the method call. – shmosel Feb 18 '15 at 00:03
  • Note this is not optimization – JamesB Feb 18 '15 at 00:04
  • @VD so this is a scenario that cannot be optimized? I suppose some NP class of problem..? – gfot Feb 18 '15 at 00:04
  • @shmosel that means that eventually will be one call? – gfot Feb 18 '15 at 00:06
  • Yes, but it doesn't happen on the JVM, and there's no guarantee. The compiler will generally optimize where it can. – shmosel Feb 18 '15 at 00:07
  • 1
    "Method calls" aren't a thing in assembly code. So you could say it will do zero method calls (because they don't exist) or you could say it will always do two method calls (at the source or bytecode level, because that's what you wrote) – user253751 Feb 18 '15 at 00:08
  • as i mentioned, simply speaking, machine will do things whatever you instruct them to do, also method call optimization is something which java leaves to developers to decide. – dev2d Feb 18 '15 at 00:09
  • @immibis I'm not sure I agree with that. You pushing the variables and the return address on to the stack is a method call in assembly. – Isaiah van der Elst Feb 18 '15 at 00:12
  • @IsaiahvanderElst it's a function call, but who said the JIT maps methods to assembly functions in any understandable way? – user253751 Feb 18 '15 at 00:14
  • @immibis There's no difference between a method call and a function call other than an extra pointer being on the stack – Isaiah van der Elst Feb 18 '15 at 00:16
  • @IsaiahvanderElst method calls are not required to push anything on any stacks. – user253751 Feb 18 '15 at 00:19
  • BTW, you could also say the JVM creates 50 invisible wrapper methods, does 52 method calls, and doesn't show those methods in stack traces, because there's no observable difference in behavior. – user253751 Feb 18 '15 at 00:20
  • @immibis Sure it is... How else would your reference "this"... you can't save that off to the heap – Isaiah van der Elst Feb 18 '15 at 00:20
  • @shmosel you're right, apparently I didn't search enough.. but very constructive comments thx! – gfot Feb 18 '15 at 00:28
  • @IsaiahvanderElst so if the JIT inlines a call, it should still make sure to redundantly push `this`? I can imagine the possibility where `this` might even be hard-coded in assembly, if the JVM can deduce that the object is a singleton. – user253751 Feb 18 '15 at 00:36
  • @immibis That's not possible. "this" is a reference to a block of data representing the state of the "object". The value is variable per instance. The only time I could see the JIT compiling code that does not push a reference to the current object to the stack is if the call is stateless (if it might as well be static). – Isaiah van der Elst Feb 18 '15 at 00:44
  • @IsaiahvanderElst so inlining is impossible and that singleton optimization I just thought of is impossible? – user253751 Feb 18 '15 at 00:48
  • @immibis your trying to find edge cases to discredit me. The fact is that there are method and function calls in assembly. – Isaiah van der Elst Feb 18 '15 at 00:51

1 Answers1

0

You are talking about inlining of method wrapperMethodArg1.

The answer is: You cannot tell in advance. The compiler will probably not inline it as this prevents reflection invocation, but the JVM might do it dynamically at runtime if the method is called often enough to be optimized.

isnot2bad
  • 24,105
  • 2
  • 29
  • 50
  • If it's ever optimized, it's going to be at run time when the JIT does it's analysis. I doubt the Java compiler would take it out the same way the g++ compiler would. – Isaiah van der Elst Feb 18 '15 at 00:14