RFR: 8253079: DeterministicDump.java fails due to garbage in structure padding [v2]

[Aleksey Shipilev]

On Mon, 21 Sep 2020 05:23:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> (EDITED) In product builds, when `PackageEntry` and `ModuleEntry` objects are allocated, the memory is not zeroed. As a
>> result, the structure padding slots (such as the 32-bits after `BasicHashtableEntry::_hash`) may contain garbage values
>> that are different on every run of `java -Xshare:dump`. As a result, `java -Xshare:dump` cannot reproduce deterministic
>> result.  The fix is to clear the memory for the newly allocated `HashtableEntry` objects when `DumpSharedSpaces ==
>> true`.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
> the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last
> revision:
>  - Zero out memory for newly allocated HashtableEntry
>  - Merge branch 'master' of https://github.com/iklam/jdk into 8253079-DeterministicDump-test-fails-product-build
>  - Revert "8253079: runtime/cds/DeterministicDump.java fails due to garbage in structure padding"
>    
>    This reverts commit d380e0213283f5f28889d867bb2505a91781df6e.
>  - 8253079: runtime/cds/DeterministicDump.java fails due to garbage in structure padding

src/hotspot/share/classfile/moduleEntry.cpp line 457:

> 455:     _location = ArchiveBuilder::get_relocated_symbol(_location);
> 456:   }
> 457:   JFR_ONLY(memset(trace_id_addr(), 0, sizeof(traceid)));

`memset` looks dodgy here. Maybe `JFR_ONLY(set_trace_id(0))`?

src/hotspot/share/classfile/packageEntry.cpp line 241:

> 239:   _qualified_exports = (GrowableArray<ModuleEntry*>*)archived_qualified_exports;
> 240:   _defined_by_cds_in_class_path = 0;
> 241:   JFR_ONLY(memset(trace_id_addr(), 0, sizeof(traceid)));

Ditto, `JFR_ONLY(set_trace_id(0))`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/267