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

[Yumin Qi]

On Sun, 20 Sep 2020 05:37:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In product builds (-O3 without -g), when initializing a `PackageEntry`, gcc for x64 stores garbage into the structure
> padding slot behind `BasicHashtableEntry::_hash` in `BasicHashtable<F>::new_entry()`. The garbage value turns out to be
> the upper bits of a `Symbol*`, which are different on every run of `java -Xshare:dump`. As a result,
> `java -Xshare:dump` cannot reproduce deterministic result.  The fix is to avoid copying contents of the structure
> padding slots when copying `PackageEntry` and `ModuleEntry` objects into the CDS archive.

The implementation is quite complex, every derivatives from BasicHashTableEntry need to have a copy_from function to
avoid such problem. Maybe a brutal one to avoid such padding issue for all cases is fill the object allocated in
AllocateHeap with \0?

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

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