Is it easy/possible to run code with 32 bit pointers on a modern 64 bit OS?

[Hal Murray]

>> It's the pointers in each list member.  If nothing else, a list
>> member will have a pointer to the next member.  The MRU list has
>> next, previous, and next-hash-chain pointers.

> Ouch, I'd try to fix that.   Maybe a different list layout model?

> Given the churn in the MRU list it may be a linked list is best.
> But worth a look.

Any suggestions?  I can't think of any obvious way to do better.

The code has a hash table to find existing slots.  It has a linked list for 
the IP addresses that hash to the same slot.  It keeps a linked list of slots 
sorted by age.  That has next and previous links to you can remove a slot and 
move it to the head.  That also lets you find the oldest slot so you can 
consider recycling it.

We could rewrite the code to use a big array.  That requires the space to be 
contiguous.  We could either pre-allocate the max size or copy over the whole 
thing when growing it.  Neither is attractive.

That's assuming array indexes would be smaller than pointers.

We could give each slot a sequential slot number rather than index.  That needs a big table/array of pointers indexed by slot number.  That trades 3 pointers for 1 pointer plus 3 indexes.  If indexes are 32 bits, that's 3*8 vs 1*8+3*4 for a savings of 4 bytes.  I don't think that's worth the complexity.  If indexes would fit in 21 bits, we could pack 3 of them into 8 bytes.  That would save 4 more bytes, but it limits us to 2 million slots.  I'm already using 3 million.

Time to move on.  There is plenty of lower hanging fruit.



-- 
These are my opinions.  I hate spam.