|Title||Epoch number can wrap around on 32-bit platforms|
|Assigned user||Gareth Rees|
|Description||The epoch number is stored in an Epoch, which is a typedef for Size, and on 32-bit platforms (such as Windows) this is a 32-bit number. There are about 2^32 centiseconds in a year, so a long-running application that collects frequently can cause this number to wrap around on a timescale of years.|
|Analysis||We could change Epoch so that it gets 64 bits even on 32-bit Windows (the type needs to be unsigned long long to get 64 bits in Visual Studio). The only places where an epoch number is stored is in the ArenaStruct  and in mps_ld_s  (where mps_word_t is used), so the memory consequences are not severe (an additional 4 bytes for each client structure containing an mps_ld_s).|
When the epoch number overflows, what will actually go wrong?
* LDAge: fine.
* LDIsStaleAny: the assertion AVER(ld->_epoch <= arena->epoch) will go off. But if that is ignored, the function seems OK: the subtraction arena->epoch - ld->_epoch will wrap around correctly.
* LDMerge: two assertions will go off. And if those are ignored, it can pick the wrong epoch for the merged LD (it uses the test "from->_epoch < ld->_epoch", but this will no longer be reliable). Incorrect merges might happen less often if the test were changed to "arena->epoch - from->_epoch > arena->epoch - ld->_epoch".
|Created by||Gareth Rees|
|Created on||2014-03-07 09:55:05|
|Last modified by||Gareth Rees|
|Last modified on||2014-10-25 23:14:47|
|History||2014-03-07 GDR Created.|