On Aug 23, 2008, at 00:59, Peter B. West wrote:

Jeremias Maerki wrote:
There's a lot of AND-ing of hash codes to determine the segments and
buckets and that's much easier to handle if you have a power of 2 and
can shift bits around.
On 22.08.2008 16:22:05 Peter B. West wrote:
Jeremias Maerki wrote:
Ok, here's the final patch I'd propose to fix the memory leak. I've seen no measurable performance degradation compared to the base revision and no multi-threading problems. The memory leak is fixed and the number of
stale references remains low.

Feedback welcome.

What happens is SEGMENT_COUNT is not a power of 2? Or, what obliges SEGMENT_COUNT to be a power of 2?


That was my assumption when I saw 'MASK', in which case is it not safer to ensure that your value is in fact all ones?


Hmm... safer? I do agree that this better reflects what is happening in this case, but in general...

For a power as low as 5, there is only little difference, except that bit-shifting may just be a tad faster; it used to be on older hardware, and may still be so, due to the lack of bounds checking, which brings us to the case of larger powers ( >= 32, or 64 ). For larger exponents, using a mathematical rather than a bitwise operator, if the result would be too large, one would at least get an overflow error. With a bitwise operator, the leftmost bits will be shifted into oblivion. No warning/error will be issued whatsoever.

Writing it in Hex, as 0x1F or (0x20 - 1) seems to be as common a practice as any. Of course, if Java would allow one to express the value in binary, that would make it even clearer...

But, now that you mention it, I think the relationship is turned upside-down in the latest patch. Actually, the SEGMENT_COUNT should depend on the SEGMENT_MASK (instead of the other way around).

Talking safety, maybe the following:

int SEGMENT_MASK = 0x1F; //binary ( 0000 0000 0000 0000 0000 0000 0001 1111 )
int SEGMENT_COUNT = SEGMENT_MASK + 1; //will cause an overflow error if SEGMENT_MASK is set to Integer.MAX_VALUE or greater



Reply via email to