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