Re: Fix object re-hashing

Linus Torvalds [off-list ref] writes:

Anyway, if all this makes you nervous,...

I did draw an illustration like the one I sent in my previous
message when I received the first patch from Johannes, and it was
reasonably obvious to me that it was meant to redistribute about
half of the existing entries to the upper area, always going
upwards, so modulo that wraparound corner case you fixed, I
think doubling is fine.

Btw, as it currently stands, I worry a tiny tiny bit about the

	obj_allocs = (obj_allocs < 32 ? 32 : 2 * obj_allocs)

thing, because I think that second "32" needs to be a "64" to be really 
safe (ie guarantee that the new obj_allocs value is always at least twice 
the old one).

obj_allocs starts out as 0 so the first value it gets is 32 when
you need to insert the first element.

On Sun, 12 Feb 2006, Junio C Hamano wrote:

quoted

Btw, as it currently stands, I worry a tiny tiny bit about the

	obj_allocs = (obj_allocs < 32 ? 32 : 2 * obj_allocs)

thing, because I think that second "32" needs to be a "64" to be really 
safe (ie guarantee that the new obj_allocs value is always at least twice 
the old one).

obj_allocs starts out as 0 so the first value it gets is 32 when
you need to insert the first element.

Yes. The point being that the code is "conceptually wrong", not that it 
doesn't work in practice. If we somehow could get into the situation that 
we had a hash size of 31, resizing it to 32 would be incorrect.

Of course, if we just make it a rule that the hash size must always be a 
power-of-two (add a comment, and enforce the rule by changing the modulus 
into a bitwise "and"), then that issue too goes away.

			Linus