The problem is described here: https://blogs.oracle.com/java-platform-group/java-se-support-for-docker-cpu-and-memory-limits

For memory limits, the maximum Java heap size can also be set explicitly via JVM command line option, -Xmx. However, in cases where none of the aforementioned JVM command line options are specified, when a Java application using Java SE 8u121 and earlier, when run in a Docker container, the JVM will use the underlying host configuration of CPUs and memory when transparently determining the number of GC threads, JIT compiler threads and maximum Java heap to use.

As the NBI image is built on top of openjdk-8, apparently it is affected.

According to the article, two flags -XX:+UnlockExperimentalVMOptions and -XX:+UseCGroupMemoryLimitForHeap should be set to avoid this kind of problem.

The -XX:+UnlockExperimentalVMOptions is required because in a future release transparent identification of Docker memory limits is the goal. When these two JVM command line options are used, and -Xmx is not specified, the JVM will look at the Linux cgroup configuration, which is what Docker containers use for setting memory limits, to transparently size a maximum Java heap size.