[11] RFR(M) 8201850: [AOT] vm crash when run test compiler/aot/fingerprint/SelfChangedCDS.java

[Ioi Lam]

Also, would be it possible to generate code inside the .so library to 
record the shift size, and trigger an assert if the runtime shift size 
is different than expected?

That way, even if the VM loads the .so file by mistake (e.g., in the 
future someone introduced a bug in AOTLoader::universe_init), the 
problem will be caught early on and won't cause mysterious crashes?

Thanks

- Ioi


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?
>
> Thanks
> - Ioi
>
> On 4/19/18 9:56 AM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8201850/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8201850
>>
>> The problem is AOT enforces not 0 compressed oop shift value (AOT 
>> uses logMinObjAlignment [1]) 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.
>>
>> Regards,
>> Vladimir
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk/jdk/file/d5c43e9f08fb/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/AOTGraalHotSpotVMConfig.java#l33
>