Java Memory Puzzle

[tuxedo]

Liest jmd. von euch regelmäßig den "The Java(tm) Specialist Newsletter"?

Da gabs gestern eine neue Ausgabe von mit einem recht "coolen" Puzzle:

public class JavaMemoryPuzzle {
  private final int dataSize =
      (int) (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzle jmp = new JavaMemoryPuzzle();
    jmp.f();
  }
}

Diese Source führt unweigerlich zu einer OutOfMemoryException. Wieso? Gute Frage. Eigentlich müsste die data Variable nur in ihrem eigene Scope leben vom GC rechtzeitig, bevor data2 allokiert wird, wieder abgeräumt werden. Fakt ist aber das dem in diesem Sample nicht so ist.

public class JavaMemoryPuzzlePolite {
  private final int dataSize =
      (int) (Runtime.getRuntime().maxMemory() * 0.6);

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }

    for(int i=0; i<10; i++) {
      System.out.println("Please be so kind and release memory");
    }
    byte[] data2 = new byte[dataSize];
  }

  public static void main(String[] args) {
    JavaMemoryPuzzlePolite jmp = new JavaMemoryPuzzlePolite();
    jmp.f();
    System.out.println("No OutOfMemoryError");
  }
}

Diese Code hingegen läuft problemlos. Ich hab mich da auch mal dran versucht und ein wenig gebastelt. Scheinbar reicht ein winzig kleines Codefragment zwischen den zwei byte[] Allokationen aus damit der GC aufräumt.

Die Frage die sich jetzt stellt: Wieso und warum ist das so?

Meine Antwort die ich eingeschickt hatte war: Der GC läuft in einem asynchronen Thread im Hintergrund und hat im ersten Beispiel einfach keine Zeit aufzuräumen. Im zweiten Beispiel hingegen reicht es um den GC zu triggern, so dass aufgeräumt wird.
Zweite Vermutung: Das allokieren hat gegenüber dem aufräumen eine höhere Prio in der JVM.

Beide Möglichkeiten wurdem vom Newsletterauto Heinz als falsch abgelehnt.
Ist hier jemand so schlau und findet die Lösung?

- Alex

 

[Schandro]

Es liegt anscheinend dadran, dass eine weitere Variable initialisiert wird (in deinem Fall "i"):
Beispiel:

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }
	boolean b = true;
    byte[] data2 = new byte[dataSize];
  }

Es kommt keine "Heap Space" Exception.



Wenn du nur schreibst:

  public void f() {
    {
      byte[] data = new byte[dataSize];
    }
	boolean b;
    byte[] data2 = new byte[dataSize];
  }

Kommt eine.

Keine Ahnung warum das so ist, aber mit der Zeit hat es nichts zu tun. Man kann auch ein Thread.sleep zwischen die beiden Arraydeklarationen schreiben, und es kommt trotzdem eine Heap Space Exception

 

[tuxedo]

Ja, dass es mit einem einfachen "byte b = 0;" auch geht wusste ich schon. Die Frage ist: Was steckt dahinter? Wieso ist das so? Logisch gesehen müsste das erste Codesnippet auch so funktionieren.

- Alex

 

[Marco13]

Hab' festgestellt, dass der "kritische Wert" (also dieser Faktor 0.6 im Beispiel) zwischen 0.464 und 0.466 liegt, und
-XX:+UseConcMarkSweepGC bzw
-XX:-UseConcMarkSweepGC
einen unterschied machen - ich schätze, es hängt mit der genauen Arbeitsweise des Mark-And-Sweep in Java zusammen (hier Question of the month: 1.4.1 Garbage collection algorithms, January 29th, 2003 steht ein bißchen was dazu), aber für genauere Tests hab' ich gerade keine Zeit...

 

[tuxedo]

Na der der Wert von 60% kommt einfach daher, dass man definitiv nicht zwei mal 60% des Speicher allokieren kann. Weil 120% Speicher allokieren wäre schon ne coole Sache

Und dein ermittelter Wert von knapp unter 50% ist einfach die mögliche Grenze. Bsp mit 46,6% ..

Programm allokiert 2x46,6%=93,2% ...
Die restlichen 6,8% wird die Anwendung anderweitig schon in Gebrauch haben (geladene Klassen, was weiß ich, ...)

Aber Mark-Sweep wird da sicher in eine nicht allzu falsche Richtung gehen. Bin ja mal gespannt auf die offizielle Auflösung des Rätsels.

- Alex

 

[Marco13]

Spontan-Intuitiv geraten würde ich GANZ grob sowas vermuten wie:
Wenn der Block verlassen wird, wird geMarkt,
aber geSweept wird erst, nachdem(!) mindestens ein byte neuer Speicher angefordert wurde

Aber der GC ist an sich wohl schon ... recht kompliziert, d.h. die genaue (und: fundierte(!)) Begründung kennt man wohl nur, wenn man sich lange und intensiv mit diesem speziellen Thema beschäftigt hat...

 

[tuxedo]

Hier gibt's übrigens die Auflösung des Rätsels:

[JavaSpecialists 174] - Java Memory Puzzle Explained

Gruß
Alex