On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam <ik...@openjdk.org> wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments >> in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random >> bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in >> make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. >> This will be fixed in >> [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, >> windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit > since the last revision: > > Fixed zero build
Hi Ioi, some questions, comments inline. Like David in the comments, I am also a bit vague on the usefulness, but I may not know the whole story. Is it to enable repackagers like Debian to check the "reproducable" tickbox on their OpenJDK package? Or is there a practical need for this? Thanks, Thomas src/hotspot/share/prims/jvm.cpp line 2887: > 2885: return; > 2886: } > 2887: #endif Should we do this for jni_AttachCurrentThread too? src/hotspot/share/utilities/hashtable.hpp line 42: > 40: > 41: LP64_ONLY(unsigned int _gap;) > 42: For 64-bit, you now lose packing potential in the theoretical case the following payload does not have to be aligned to 64 bit. E.g. for T=char, where the whole entry would fit into 8 bytes. Probably does not matter as long as entries are allocated individually from C-heap which is a lot more wasteful anyway. For 32-bit, I think you may have the same problem if the payload starts with a uint64_t. Would that not be aligned to a 64-bit boundary too? Whether or not you build on 64-bit? I think setting the memory, or at least the first 8..16 bytes, of the entry to zero in BasicHashtable<F>::new_entry could be more robust: (16 bytes in case the payload starts with a long double but that may be overthinking it :) template <MEMFLAGS F> BasicHashtableEntry<F>* BasicHashtable<F>::new_entry(unsigned int hashValue) { char* p = :new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F); ::memset(p, 0, MIN2(this->entry_size(), 16)); // needs reproducable BasicHashtableEntry<F>* entry = ::new (p) BasicHashtableEntry<F>(hashValue); return entry; } If you are worried about performance, this may also be controlled by a template parameter, and then you do it just for the system dictionary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748