0

I generate a sequence of bytecode after inline multiple method invocation. At the beginning of inline, I first poped existing variable indexes to a new local variable numbers in case of any exception in the inlined method. This operation results to a number of xLOAD and xStore sequence in the final bytecodes. The sample is:

   GETFIELD DYNGuardWithTestHandle1456194204777.guard : Ljava/lang/invoke/MethodHandle;
    INVOKEVIRTUAL java/lang/invoke/MethodHandle.invokeExact ()Z
    IFEQ L0
    ALOAD 0
    ALOAD 1
    ALOAD 2
    ALOAD 3
    ALOAD 4
    ASTORE 5
    ASTORE 6
    ASTORE 7
    ASTORE 8
    ASTORE 9
    ALOAD 9
    ALOAD 8
    ALOAD 7
    ALOAD 6
    ALOAD 5
    ASTORE 10
    ASTORE 11
    ASTORE 12
    ASTORE 13
    ASTORE 14
    ALOAD 14
    GETFIELD DYNGuardWithTestHandle1456194204777.trueTarget_guard_next : Ljava/lang/invoke/MethodHandle;
    LDC "fd1a2fc6-03ef-4fd8-a2ae-ebbaa274fa97"
    INVOKESTATIC java/lang/invoke/ObjectTransfer.peek (Ljava/lang/String;)Ljava/lang/Object;
    CHECKCAST org/jruby/RubyClass
    ALOAD 11
    INVOKEVIRTUAL java/lang/invoke/MethodHandle.invokeExact (Lorg/jruby/RubyClass;Lorg/jruby/runtime/builtin/IRubyObject;)Z
    GOTO L1
   L1
    IFEQ L2
    ALOAD 9
    ALOAD 8
    ALOAD 7
    ALOAD 6
    ALOAD 5
    ASTORE 15
    ASTORE 16
    ASTORE 17
    ASTORE 18
    ASTORE 19
    ALOAD 19
    ALOAD 16
    ALOAD 18
    ALOAD 15
    ASTORE 20
    ASTORE 21
    ASTORE 22
    ASTORE 23
    ALOAD 23
    ALOAD 22
    CHECKCAST org/jruby/RubyString
    ALOAD 21
    ALOAD 20
    ASTORE 24
    ASTORE 25
    ASTORE 26
    ASTORE 27
    ALOAD 27
    ALOAD 26
    ALOAD 25
    ALOAD 24
    ASTORE 28
    ASTORE 29
    ASTORE 30
    ASTORE 31

I am wondering whether there are some well-known optimization to eliminate these xLoad/xStore sequence.

Thanks

shijie xu
  • 1,975
  • 21
  • 52

1 Answers1

1

Don't worry about it. If the method is executed a lot, the JVM will probably optimize it anyway, at which point the extra loads and stores get optimized away.

Try profiling it to see if it's even worth micro-optimizing.

Antimony
  • 37,781
  • 10
  • 100
  • 107
  • 1
    Actually, I plan to make optimization on the bytecode level, instead of leaving JIT compiler do it. My purpose whether to see there is improvement if optimization is done on the Bytecode Level – shijie xu Mar 28 '16 at 02:36
  • 1
    You can try it if you want, but the JVM is likely to render any bytecode level optimization irrelevant. – Antimony Mar 28 '16 at 16:49
  • Do you have evidence that the JVM optimizes this? – user253751 Mar 30 '16 at 07:58
  • @immibis Do you have any evidence that it doesn't? I haven studied the JVM in detail, but I did read that it does optimizations like this. If you're really worried about it, profile it yourself. – Antimony Mar 30 '16 at 13:54
  • 1
    @immibis: you can derive it from the [HotSpot white paper](http://www.oracle.com/technetwork/java/whitepaper-135217.html#server): “*The Java HotSpot Server Compiler […] uses an advanced static single assignment (SSA)-based IR for optimizations. The optimizer performs all the classic optimizations, including […] common subexpression elimination, constant propagation, [global value numbering](https://en.wikipedia.org/wiki/Global_value_numbering), and global code motion.*” (link added by me) – Holger Mar 30 '16 at 16:38
  • @Antimony You're the one making the claim, so you're the one that should provide evidence... – user253751 Mar 30 '16 at 19:41
  • @Holger Thank you. (It may still be worth testing that it happens in the latest JVM, in case of bugs etc) – user253751 Mar 30 '16 at 19:42