RFR(M) 8201850: [AOT] vm crash when run test compiler/aot/fingerprint/SelfChangedCDS.java
vladimir.kozlov at oracle.com
Thu Apr 19 22:17:44 UTC 2018
I changed test as you suggested. Now it triggers crash on big machines too:
I also tested that that AOT library will be unloaded if shift value is not set by
AOTLoader::set_narrow_oop_shift() and it mismatch with AOTed value. We getn next message:
Shared file ./libSelfChanged.so error: Universe::narrow_oop_shift has different value '3' from
Test all AOT test on machine with small (8Gb) memory where crash was reproduced and on machine with
On 4/19/18 12:46 PM, Ioi Lam wrote:
> Hi Vladimir,
> The changes look good.
> I think (?) that the original failure happened only on machines with small amount of memory so
> default heap size is small. To ensure that this scenario is always tested, in SelfChangedCDS.java,
> maybe add a new test case that specifically uses a small heap during both dump time and run time, so
> CDS will use 0 shift?
> - Ioi
> On 4/19/18 9:56 AM, Vladimir Kozlov wrote:
>> The problem is AOT enforces not 0 compressed oop shift value (AOT uses logMinObjAlignment )
>> regardless heap size to cover more cases. CDS does not do that - if heap is small (as in this
>> case) it will record 0 shift during dump.
>> Later when CDS archive is loaded into VM with the same small heap it verifies that oop shift is
>> still 0. And it is 0 at that time because Metaspace::global_initialize() which loads archive is
>> called before AOTLoader::universe_init() which reset shift value.
>> As result shared java objects (strings) in CDS archive are mapped into java heap with wrong (after
>> AOT change shift value) compressed oops encoding. GC dies because of that.
>> The propose fix is add new AOTLoader::set_narrow_oop_shift() method which is called in
>> Universe::initialize_heap() before Metaspace::global_initialize(). AOTLoader::universe_init() is
>> changed to only verify that shift value is consistent. I also added code to unload AOT library
>> with non matching configs.
>> Tested with small heap which reproduced the problem and full Mach5 testing.
>> I want especially to thank Jiangli Zhou from runtime group who did initial investigation and found
>> root cause of this problem. She also suggested and discussed with me several solutions.
More information about the hotspot-compiler-dev