|
From: Konstantin S. <kon...@gm...> - 2008-01-16 12:14:06
|
Great! Do you plan to checkin these or similar changes in future? Maybe under #ifdef so that users do not suffer if they don't need too many [TL]SETs? While I think that something like 24 bits for [TL]SETs is a must for large apps, it might not be enough. We may need some garbage collection for [TL]SETs. Once in a while we could scan all memory, collect all used [TL]SETs and prune unused. We could also do garbage collection at thread_join and mutex_destroy (not every time, of course and only if number of [TL]SETs is getting close to the limit). Anyway, I'll try the 64-bit patch to see if garbage collection is really critical. --kcc On Jan 16, 2008 12:26 AM, Julian Seward <js...@ac...> wrote: > > > [...] change SVal to 64-bit at some point (I vote for it!), > > I already did that in Nov 07, but did not commit due to increase > in run time and space usage. The resulting patch is attached. > It allows up to 24 bits for lock- and thread-set IDs. I can't > remember now why I limited it to 24 bits -- could go up to about > 30 bits. > > Really 64-bit for a SVal is too much but 32-bit is not enough. > Something like 48 bits would be a good compromise, but there is > no sensible way to do that in C. Oh well. > > The patch also changes CacheLine to have a dirty bit in an attempt > to reduce the performance overhead from writing back cache lines. > That helps, although it also adds to the complexity and overhead > of verifying that the shadow memory system is functioning > correctly. > > J > |