tomitankChess - New JavaScript engine

[hgm]

Yes, you do use always-replace strategy. But what exactly do you replace? You don't overwrite the properties of the existing HashEntry object. Instead you ask for a new HashEntry, and initialize that. If I understand this object business correctly, that would mean it gets created in a different memory location as the old HashEntry for that index. So what is replaced in the brd_HashTable array is actually the pointer to the object; instead of pointing to the old HashEntry it points now to the new HashEntry. But the old HashEntry still sits in memory somewhere. There just is no pointer pointing to it anymore.

I guess this is what garbage collection is for, that somehow the object also contains a counter that keeps track of how many times it is referenced, and that when the last reference disappears, it becomes eligible for gabage collection. Perhaps this is what Graham is seeing: that the garbage collection is a bit tardy, and allows the pile of unrefereced HashEntries to grow to 400MB before it starts acting.

BTW, I am experimenting a bit with a JavaScript Chess engine now too. (Somewhat like an early version of micro-Max). In FireFox on Linux it apparently knows Float64Array(), and I had no problems filling 2M entries of it with 1e10 (which would not fit in a 32-bit int).

[tomitank]

Yes, you do use always-replace strategy. But what exactly do you replace? You don't overwrite the properties of the existing HashEntry object. Instead you ask for a new HashEntry, and initialize that.

Maybe.
I will try this:

Code: Select all

var index = brd_hashKeyLow & HASHMASK;
if (brd_HashTable[index] != null) {
	brd_HashTable[index].move = move;
	brd_HashTable[index].flags = flags;
	brd_HashTable[index].depth = depth;
	brd_HashTable[index].score = score;
}