eliminate malloc hashtable

[derekbruening]

From bruen...@google.com on February 23, 2012 15:09:50

xref general case issue #460 first we should establish that the malloc hashtable is indeed a bottleneck with the other issue #460 opts are there and once drwrap is as fast as the dedicated impl ( issue #689 )

in my original DrMem code I didn't use a malloc hashtable b/c leaks were
off by default. the table is used to iterate allocs for leaks, to store
callstacks, to identify pre-us and native (LFH tangent) allocs, and for
alloc mismatch detection.

*** TODO store data in redzone and do Rtl heap iterate for leak scan

store callstacks and mismatch flags in redzone

for pre-us: no hashtable, have magic value, if hits also call RtlHeapSize
to be sure it's pre-us.

for pattern, where can't store in redzone: have rbtree anyway.

*** TODO get rid of hashtable and replace w/ alloc history

Qin's idea:
per-thread buffer that stores rdtsc
merge often enough to avoid rdtsc rollover
would that be faster than hashtable?

Original issue: http://code.google.com/p/drmemory/issues/detail?id=793

[derekbruening]

From zhao...@google.com on February 27, 2012 08:06:19

If malloc is not that racy, i.e. multiple threads call malloc/free at the same time all the time, I believe it is possible to have a global single buffer with fast appending and minimal lock contention.
I am more worry about the size of the buffer.

[derekbruening]

From bruen...@google.com on February 27, 2012 08:12:28

also note that we need to be able to detect an invalid free for correctness to avoid races between pre and post free instrumentation: we have to be able to accurately predict when free will fail. it's doable w/o a hashtable but something to keep in mind. certainly easier when replacing than wrapping.