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 <[EMAIL PROTECTED]> 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
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
