Strange bug inside jetty at shenandoah/jdk8u

[Kirill A. Korinsky]

Yes, this machine has a limit for docker container. But it is 6Gb.

Anyway, original bug is existed but I can't reproduce it yet on simpler case :(

I can only hide it (or make it rare?) by increasing heap.

--
wbr, Kirill


> On 19 Dec 2017, at 19:30, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> 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
>