RFR (M): Shenandoah crashes with -XX:ObjectAlignmentInBytes=16

Roman Kennke rkennke at redhat.com
Mon Sep 19 19:31:54 UTC 2016


Am Montag, den 19.09.2016, 21:15 +0200 schrieb Aleksey Shipilev:
> 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

This is awesome work! We haven't really thought about changing
alignment (I for one did not know that this is possible at all).

About tests: would be awesome to have (more) jtreg tests for Shenandoah
in the repository.

Roman



More information about the shenandoah-dev mailing list