Schreibzugriff bei jedem Überschreiben?

[Rusticus1999]

Hallo zusammen,

Ich habe mich gefragt ob Java automatisch a = b im Falle a == b nicht ausführt.

 

[mrBrown]

Vielleicht.

Damit begibst du dich in die Untiefen des JIT-Compilers, und das möchtest du nicht

 

[VfL_Freak]

BTW: bei Deiner Umfrage fehlt noch ein "weiß ich nicht"
VG Klaus

 

[thecain]

Auch wenn Java das nicht automatische machen würde, wäre ein IF davor zu packen auf jeden Fall auch nicht besser

 

[Tarrew]

Ich hab mal mit einem kleinen Beispiel ausprobiert (Java: 1.8.0_121):

    public static void main(String[] args) {

        int a = 5;
        int b = 5;

        for(int i=0; i<10000; i++) {
            a = b;
        }
      
        System.out.println(a);
    }

Daraus macht die JVM erstmal folgenden Bytecode:

         0: iconst_5
         1: istore_1
         2: iconst_5
         3: istore_2
         4: iconst_0
         5: istore_3
         6: iload_3
         7: sipush        10000
        10: if_icmpge     21
        13: iload_2
        14: istore_1
        15: iinc          3, 1
        18: goto          6
        21: getstatic     #2               
        24: iload_1
        25: invokevirtual #3                
        28: return

Zeile 13 und 14 sind hier interessant: Die Variable im Speicher wird jedes Mal überschrieben.


Wenn man das ganze leicht ändert:

    public static void main(String[] args) {
        for (int i = 0; i < 1000000; i++) {
           doSomeStuff();
        }
    }

    public static int doSomeStuff() {
        int a = 5;
        int b = 5;

        a = b;

        return a;
    }

und sich anguckt, was die JVM in Assembler daraus macht:

  # {method} {0x000000001b8c0310} 'doSomeStuff' '()I' in 'Main'
  #           [sp+0x40]  (sp of caller)
  0x0000000004ab5f60: mov     dword ptr [rsp+0ffffffffffffa000h],eax
  0x0000000004ab5f67: push    rbp
  0x0000000004ab5f68: sub     rsp,30h           ;*iconst_5
                                                ; - Main::doSomeStuff@0 (line 13)

  0x0000000004ab5f6c: mov     eax,5h
  0x0000000004ab5f71: add     rsp,30h
  0x0000000004ab5f75: pop     rbp
  0x0000000004ab5f76: test    dword ptr [5e0100h],eax  ;   {poll_return}
  0x0000000004ab5f7c: ret
  0x0000000004ab5f7d: nop
  0x0000000004ab5f7e: nop
  0x0000000004ab5f7f: mov     rax,qword ptr [r15+2a8h]
  0x0000000004ab5f86: mov     r10,0h
  0x0000000004ab5f90: mov     qword ptr [r15+2a8h],r10
  0x0000000004ab5f97: mov     r10,0h
  0x0000000004ab5fa1: mov     qword ptr [r15+2b0h],r10
  0x0000000004ab5fa8: add     rsp,30h
  0x0000000004ab5fac: pop     rbp
  0x0000000004ab5fad: jmp     4a0cae0h          ;   {runtime_call}
  0x0000000004ab5fb2: hlt
  0x0000000004ab5fb3: hlt
  0x0000000004ab5fb4: hlt
  0x0000000004ab5fb5: hlt
  0x0000000004ab5fb6: hlt
  0x0000000004ab5fb7: hlt
  0x0000000004ab5fb8: hlt
  0x0000000004ab5fb9: hlt
  0x0000000004ab5fba: hlt
  0x0000000004ab5fbb: hlt
  0x0000000004ab5fbc: hlt
  0x0000000004ab5fbd: hlt
  0x0000000004ab5fbe: hlt
  0x0000000004ab5fbf: hlt

dann sieht man auch, dass die JVM quasi die ganze Methode wegoptimiert hat, weil halt nichts drin passiert. Ist natürlich jetzt ein sehr gestellter Fall, aber wenn wenn dein Code sehr oft aufgerufen wird und die JVM den Bytecode wirklich fest in Assembler Code übersetzen sollte, dann kann man idR schon davon ausgehen, dass solche simplen statischen Sachen wegoptimiert werden. Auch wenn man natürlich nicht mit dem Vorsatz programmieren sollte, dass die JVM schon alles wegoptimiert .

Sachen wie:

    public static int doSomeStuff(int i) {
        int a = 1;
        int b = i % 2;

        a = b;

        return a+b;
    }

wurden auch optimiert, die Zuweisung findet also nicht nochmal statt. Aber verlassen sollte man sich natürlich nicht drauf, wobei so simple Zuweisungen ja ohnehin mehr oder weniger nicht messbar sind.

 

[thecain]

und das sagt noch lange nicht aus, was der JIT nachher noch daraus macht.

 

[mrBrown]

Interessant wirds allerdings erst, wenn's keine lokalen Variablen mehr sind

Da wären (volatile) static und Instanz-Variablen deutlich interessanter

Auch wenn man natürlich nicht mit dem Vorsatz programmieren sollte, dass die JVM schon alles wegoptimiert .

Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles