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

Yumin Qi minqi at openjdk.java.net
Mon Sep 21 16:45:10 UTC 2020


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

looks good!

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

Marked as reviewed by minqi (Reviewer).

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


More information about the hotspot-runtime-dev mailing list