-
Bug
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
One of
-
b20
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8245363 | 14u-cpu | Aleksey Shipilev | P4 | Resolved | Fixed | master |
| JDK-8244688 | 14.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b06 |
One of the tests that fails intermittently in Shenandoah testing is DirectBufferAllocTest. It allocates lots of DBBs and checks that JDK machinery is able to recover.
$ ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -cp ./test/jdk/java/nio/Buffer/ -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:MaxDirectMemorySize=128m DirectBufferAllocTest
<fails with OOME occasionally>
The underlying code is calling System.gc() when native memory storage is depleted, which will block until GC is over. But, there is a wrinkle in Shenandoah control code: if that request comes too late, it can unblock when *current* GC cycle is over, which would not free enough memory. Then, OOME would fire.
$ ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -cp ./test/jdk/java/nio/Buffer/ -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:MaxDirectMemorySize=128m DirectBufferAllocTest
<fails with OOME occasionally>
The underlying code is calling System.gc() when native memory storage is depleted, which will block until GC is over. But, there is a wrinkle in Shenandoah control code: if that request comes too late, it can unblock when *current* GC cycle is over, which would not free enough memory. Then, OOME would fire.
- backported by
-
JDK-8244688 Shenandoah: explicit GC request should wait for a complete GC cycle
-
- Resolved
-
-
-
- Resolved
-