Tablica bajtów Java o wielkości 1 MB lub więcej zajmuje dwa razy więcej pamięci RAM

Uruchomienie poniższego kodu w systemie Windows 10 / OpenJDK 11.0.4_x64 powoduje wygenerowanie danych wyjściowych used: 197i expected usage: 200. Oznacza to, że 200 bajtów tablic z milionem elementów zajmuje około. 200 MB pamięci RAM. Wszystko w porządku.

Kiedy zmienię przydział tablicy bajtów w kodzie z new byte[1000000]na new byte[1048576](to znaczy na 1024 * 1024 elementów), to generuje jako dane wyjściowe used: 417i expected usage: 200. Co za cholera?

import java.io.IOException;
import java.util.ArrayList;

public class Mem {
    private static Runtime rt = Runtime.getRuntime();
    private static long free() { return rt.maxMemory() - rt.totalMemory() + rt.freeMemory(); }
    public static void main(String[] args) throws InterruptedException, IOException {
        int blocks = 200;
        long initiallyFree = free();
        System.out.println("initially free: " + initiallyFree / 1000000);
        ArrayList<byte[]> data = new ArrayList<>();
        for (int n = 0; n < blocks; n++) { data.add(new byte[1000000]); }
        System.gc();
        Thread.sleep(2000);
        long remainingFree = free();
        System.out.println("remaining free: " + remainingFree / 1000000);
        System.out.println("used: " + (initiallyFree - remainingFree) / 1000000);
        System.out.println("expected usage: " + blocks);
        System.in.read();
    }
}

Patrząc nieco głębiej w visualvm, w pierwszym przypadku widzę wszystko zgodnie z oczekiwaniami:

W drugim przypadku oprócz tablic bajtowych widzę tę samą liczbę tablic int zajmujących taką samą ilość pamięci RAM, jak tablice bajtów:

Nawiasem mówiąc, te tablice int nie pokazują, że są do nich odniesienia, ale nie mogę ich wyrzucać do śmieci ... (Tablice bajtów pokazują dobrze, gdzie są odniesienia).

Jakieś pomysły, co się tutaj dzieje?

Opisuje to natychmiastowe zachowanie modułu śmieciowego G1, który zwykle domyślnie przyjmuje 1 MB „regionów” i stał się domyślnym JVM w Javie 9. Uruchamianie z włączonymi innymi GC daje różne liczby.

każdy obiekt, który jest większy niż połowa wielkości regionu, jest uważany za „humongous” ... W przypadku obiektów, które są tylko nieco większe niż wielokrotność rozmiaru regionu stosu, to niewykorzystane miejsce może spowodować fragmentację stosu.

Pobiegłem java -Xmx300M -XX:+PrintGCDetailsi pokazuje, że kupa jest wyczerpana przez ogromne regiony:

[0.202s][info   ][gc,heap        ] GC(51) Old regions: 1->1
[0.202s][info   ][gc,heap        ] GC(51) Archive regions: 2->2
[0.202s][info   ][gc,heap        ] GC(51) Humongous regions: 296->296
[0.202s][info   ][gc             ] GC(51) Pause Full (G1 Humongous Allocation) 297M->297M(300M) 1.935ms
[0.202s][info   ][gc,cpu         ] GC(51) User=0.01s Sys=0.00s Real=0.00s
...
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Chcemy, aby nasz 1MiB byte[]był „mniejszy niż połowa wielkości regionu G1”, więc dodanie -XX:G1HeapRegionSize=4Mdaje funkcjonalną aplikację:

[0.161s][info   ][gc,heap        ] GC(19) Humongous regions: 0->0
[0.161s][info   ][gc,metaspace   ] GC(19) Metaspace: 320K->320K(1056768K)
[0.161s][info   ][gc             ] GC(19) Pause Full (System.gc()) 274M->204M(300M) 9.702ms
remaining free: 100
used: 209
expected usage: 200

Szczegółowy przegląd G1: https://www.oracle.com/technical-resources/articles/java/g1gc.html

Szczegóły kruszenia G1: https://docs.oracle.com/en/java/javase/13/gctuning/garbage-first-garbage-collector-tuning.html#GUID-2428DA90-B93D-48E6-B336-A849ADF1C552