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