RFR(S) 8244536 cds/DeterministicDump.java failed: File content different

Calvin Cheung calvin.cheung at oracle.com
Fri May 15 05:51:43 UTC 2020


Hi Ioi,

The updated test looks good.

thanks,

Calvin

On 5/14/20 9:03 PM, Ioi Lam wrote:
> Hi Calvin,
>
> Actually, the "compressed" mode is not available on 32-bit, so we 
> shouldn't test with compressed==true.
>
> I've changed the test case a little to make it less confusing.
>
> http://cr.openjdk.java.net/~iklam/jdk15/8244536-DeterministicDump-fails-on-windows.v02/ 
>
>
> What do you think?
>
> Thanks
> - Ioi
>
> On 5/13/20 11:53 AM, Calvin Cheung wrote:
>> Hi Ioi,
>>
>> In the testcase, I'm wondering would it make sense to throw a 
>> SkippedException instead of just return?
>>
>>   58             if (compressed) {
>>   59                 return;
>>   60             }
>>
>> thanks,
>>
>> Calvin
>>
>> On 5/11/20 2:00 PM, Ioi Lam wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8244536
>>> http://cr.openjdk.java.net/~iklam/jdk15/8244536-DeterministicDump-fails-on-windows.v01/ 
>>>
>>>
>>> I fixed 2 issues that are likely to happen on Windows due to
>>> it aggressive ASLR policy (address space layout randomization).
>>> These would cause the CDS archive to have non-deterministic
>>> contents:
>>>
>>> [1] Don't save the _narrow_oop_{mode,shift,base} header fields
>>>     for platforms (including Windows) that don't support heap
>>>     archiving, as these fields would be useless anyway.
>>>
>>>     This was the cause of the failure cases in the bug report.
>>>
>>> [2] Fixed a hashtable that would lay out differently if
>>>     the archive was relocated during -Xshare:dump. This is also
>>>     likely to happen on Windows but is not as frequent as #1.
>>>
>>>     Added test case for [2] in DeterministicDump.java (using
>>>     -XX:ArchiveRelocationMode=1).
>>>
>>>
>>> Test on mach5 with tiers 1/2/3.
>>>
>>> Thanks
>>> - Ioi
>


More information about the hotspot-runtime-dev mailing list