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

[Jie Fu]

On Mon, 21 Sep 2020 05:23:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> 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?
>
>> 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?
> 
> You're right. My original analysis was wrong: set_hash() didn't write garbage into the padding. Instead, the garbage
> was there because AllocaHeap didn't initialize the new buffer in product builds.
> I reverted the original fix. Instead, I added code to call memset() when allocating a new hashtable entry (but only
> when DumpSharedSpaces is true).

It passed with this fix.
Looks good to me.
Thanks.

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

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