Strange bug inside jetty at shenandoah/jdk8u

[Aleksey Shipilev]

On 12/14/2017 11:29 PM, Kirill A. Korinsky wrote:
> Looks like I found issue that creates strange behaviour and broke starting an application at your
> fastdebug image 
> 
> ➜  ~docker run --rm -ti shipilev/openjdk:8-shenandoah-fastdebug bash
> root at 27a293be90b2:/# java -Xmx4096m -Xms4096m -version
> Killed
> root at 27a293be90b2:/# java -Xmx4096m -version
> openjdk version "1.8.0-internal-fastdebug"
> OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-jenkins_2017_11_15_05_12-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00-fastdebug, mixed mode)
> root at 27a293be90b2:/# exit
> exit
> ➜  ~docker run --rm -ti shipilev/openjdk:8-shenandoah bash          
> root at 10aa56f25cb7:/# java -Xmx4096m -Xms4096m -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-jenkins_2017_11_15_03_20-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)
> root at 10aa56f25cb7:/# exit
> exit
> ➜  ~docker images | grep shenandoah                       
> shipilev/openjdk         8-shenandoah-fastdebug   ec13bdd01380        4 weeks ago         383MB
> shipilev/openjdk         8-shenandoah            cb7dbc6f6fb9        4 weeks ago         385MB
> ➜  ~ 
> 
> Yes, I just removed `-Xms` from arguments and it helps:
>  - it starts at fastdebug image;
>  - it doesn't crash at ab test.

This is weird, can't reproduce it. I guess this means JVM is blowing per-container memory limits,
and then gets killed by OOM killer. It explains why only fastdebug builds are failing: they zap the
heap with magic values and thus commit all the memory in. When -Xms4g is set, it overflows the limit
and gets killed. When -Xms is not set, we commit less, and do not blow up. With release bits, we
"commit" the heap with -Xms4g, but Linux memory subsystem does not actually allocate pages until we
write into them.

If that is true, then -XX:+AlwaysPreTouch with release builds would also fail.

Thanks,
-Aleksey