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

[Yumin Qi]

HI, Ioi

   I have a question here:

    _version = CURRENT_CDS_ARCHIVE_VERSION;
    _alignment = alignment;
    _obj_alignment = ObjectAlignmentInBytes;
    _compact_strings = CompactStrings;
+ if (HeapShared::is_heap_object_archiving_allowed()) {
    _narrow_oop_mode = CompressedOops::mode();
    _narrow_oop_base = CompressedOops::base();
    _narrow_oop_shift = CompressedOops::shift();
+ _heap_end = CompressedOops::end();
+ }
    _compressed_oops = UseCompressedOops;
    _compressed_class_ptrs = UseCompressedClassPointers;
    _max_heap_size = MaxHeapSize;
    _narrow_klass_shift = CompressedKlassPointers::shift();
- if (HeapShared::is_heap_object_archiving_allowed()) {
- _heap_end = CompressedOops::end();
- } _heap_end seems not calculated if heap object not archived.



Thanks
Yumin

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