On Fri, 30 Jul 2021 20:14:04 GMT, Zhengyu Gu <[email protected]> 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
