RFR: 8253079: DeterministicDump.java fails due to garbage in structure padding [v3]
Ioi Lam
iklam at openjdk.java.net
Mon Sep 21 22:19:04 UTC 2020
> (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 incrementally with one additional commit since the last revision:
also reset trace_id
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/267/files
- new: https://git.openjdk.java.net/jdk/pull/267/files/225c9272..5706a821
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=267&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=267&range=01-02
Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/267.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/267/head:pull/267
PR: https://git.openjdk.java.net/jdk/pull/267
More information about the hotspot-runtime-dev
mailing list