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

[Ioi Lam]

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