Java байтовый массив размером 1 МБ или больше занимает в два раза больше оперативной памяти

Выполнение приведенного ниже кода в Windows 10 / OpenJDK 11.0.4_x64 приводит к выводу used: 197и expected usage: 200. Это означает, что 200-байтовые массивы из одного миллиона элементов занимают ок. 200 МБ ОЗУ. Все прекрасно.

Когда я изменяю распределение байтового массива в коде с new byte[1000000]на new byte[1048576](то есть до 1024 * 1024 элементов), он выдает в качестве вывода used: 417и expected usage: 200. Какого черта?

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();
    }
}

Глядя немного глубже с visualvm, я вижу в первом случае все как и ожидалось:

Во втором случае, в дополнение к байтовым массивам, я вижу такое же количество массивов int, занимающих тот же объем ОЗУ, что и байтовые массивы:

Кстати, эти int-массивы не показывают, что на них ссылаются, но я не могу собрать их ... (Байт-массивы прекрасно показывают, где на них ссылаются.)

Есть идеи, что здесь происходит?

Это описывает готовое поведение сборщика мусора G1, который по умолчанию имеет значение «регионы» 1 МБ и становится Java по умолчанию в Java 9. Запуск с другими включенными GC дает различные числа.

любой объект, размер которого превышает половину области, считается «огромным» ... Для объектов, которые немного превышают размер области кучи, это неиспользуемое пространство может привести к фрагментации кучи.

Я побежал, java -Xmx300M -XX:+PrintGCDetailsи это показывает, что куча истощена огромными регионами:

[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

Мы хотим, чтобы наш 1MiB byte[]был «меньше половины размера области G1», поэтому добавление -XX:G1HeapRegionSize=4Mдает функциональное приложение:

[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

Подробный обзор G1: https://www.oracle.com/technical-resources/articles/java/g1gc.html

Дробящая деталь G1: https://docs.oracle.com/en/java/javase/13/gctuning/garbage-first-garbage-collector-tuning.html#GUID-2428DA90-B93D-48E6-B336-A849ADF1C552