RFR (M): Shenandoah crashes with -XX:ObjectAlignmentInBytes=16
Aleksey Shipilev
shade at redhat.com
Mon Sep 19 19:15:56 UTC 2016
Hi,
I have accidentally ran Shenandoah with -XX:ObjectAlignmentInBytes=16
while doing JOL development, and it crashed spectacularly. Note that
this is the option that some users enable to get compressed oops on > 32
Gb heap. While the tradeoff due to reserving the space for Brooks
pointers is shadier with Shenandoah, we definitely should not crash.
This lead me to study the Brooks pointer mechanics, and made me realize
we have several problems:
a) Allocating 8 bytes for Brooks pointer is not enough to maintain
alignment larger 8 in our current allocation mechanics. We have to
reserve the space that agrees with MinObjectAlignment. Unfortunately,
this makes BrooksPointer offset/size calculation depend on runtime
values, and therefore no more static consts for us anymore.
b) We have all these -8/-1 constants spread around the codebase, so
changing the Brooks pointer size is not something that came easily.
After reading the diff against the mainline, I think I spotted all the
cases, and rewritten their magic values to proper definitions.
c) There are no Shenandoah-specific GC tests in the repo to sanity test
it? Added a very basic regression test for this issue. (Still struggling
to make JTReg run it though, "Error: cannot determine version for JDK",
runs fine standalone).
All three are hopefully addressed here:
http://cr.openjdk.java.net/~shade/shenandoah/brooks-align/webrev.01/
Thoughts?
Thanks,
-Aleksey
More information about the shenandoah-dev
mailing list