ADDITIONAL SYSTEM INFORMATION :
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)

Linux 4.4.0-141-generic #167-Ubuntu x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
We have a rather memory intense data import procedure with "-Xmx230g" and using the latest JDK11 it nearly always crashes at the same point although enough memory should be available:

2019-01-09 13:21:26.337 [main] INFO c.g.r.ee.AverageSpeedCalculator - reading raster ./routing-ee/files/speedmodels/innerMunich.tif ...totalMB:235520, usedMB:123664
2019-01-09 13:21:28.847 [main] INFO c.g.r.ee.AverageSpeedCalculator - reading raster ./routing-ee/files/speedmodels/innerLondon.tif ...totalMB:235520, usedMB:124816
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 5392 bytes for AllocateHeap
# An error report file with more information is saved as:
# /install/enterprisegh/matrix/hs_err_pid26499.log
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f74a4ba4000, 65536, 1) failed; error='Not enough space' (errno=12)
[thread 26510 also had an error]

This did not happen for JDK8 and does not happen with the parallel GC in JDK11

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The part where it is crashing is closed source code but I can give you the hs_err_pid26499.log
https://gist.github.com/karussell/b31ade897d9dd4a2958461ca36de76fc

And our code is based on: https://github.com/graphhopper/graphhopper

See OSMReader. Then in our closed source code we we read 6 tif files that use in a clean environment roughly 4GB of RAM. We do this with com.twelvemonkeys.imageio:imageio-tiff:3.2.1

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Not crashing the JVM
ACTUAL -
It crashed the JVM (except for a freshly restarted server)

CUSTOMER SUBMITTED WORKAROUND :
Using -XX:+UseParallelGC

FREQUENCY : always