RFR: JDK-8256844: Make NMT late-initializable [v2]

[Thomas Stuefe]

On Fri, 30 Jul 2021 20:14:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - feedback zhengyu
>>  - feeback Coleen/Kim (constness fix)
>>  - Feedback David
>>  - Add test to test for non-java launcher support of NMT
>>  - move all test code to gtest
>>  - actually free blocks freed in pre-init phase
>
> src/hotspot/share/services/nmtPreInit.hpp line 153:
> 
>> 151: 
>> 152:   static unsigned calculate_hash(const void* p) {
>> 153:     uintptr_t tmp = p2i(p);
> 
> malloc memory usually is 2-machine word aligned, maybe tmp = tmp >> LP64_ONLY(4) NOT_LP64(3) can result better hash distribution?

I thought so too at first, but it is not necessary. The hash function uses all input bits:

    uintptr_t tmp = p2i(p);
    unsigned hash = (unsigned)tmp
                     LP64_ONLY( ^ (unsigned)(tmp >> 32));

p2i is lossless since input and result have the same size.
Then,
- for 32-bit, it does not matter since unsigned is the same size as uintptr_t and we lose no bits
- for 64-bit, we xor the upper half of the 64-bit input value into the lower half; again, all input bits count toward the result. We don't gain anything by shifting, we would just exchange the lower 2 bits always being zero against the upper 2 bits always being zero.

---

BTW, I experimented with different hash functions, e.g. http://www.concentric.net/~Ttwang/tech/inthash.htm, but did not really get a better distribution. This somewhat mirrors my experiences when I tried to optimize your hash function in the MallocSiteTable. Seems malloc return value is already "random enough". I coupled it with a crooked table size though, made it a prime.

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

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