delay start of memory checking #130
Comments
|
From bruen...@google.com on April 10, 2012 11:10:27 there are several variants here:
xref DRi#725: attach feature on Windows Labels: -Priority-Low Priority-High Performance |
|
From bruen...@google.com on April 11, 2012 12:58:34 further options include using probe mode up front to monitor mallocs w/o code cache cost, and giving up on invalid heap args and not bothering w/ heap walk. xref issue #794 Owner: bruen...@google.com |
|
From zhao...@google.com on June 04, 2012 13:46:51 Issue 905 has been merged into this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
From derek.br...@gmail.com on December 10, 2010 17:57:53
PR 424531
If the heap walk (for PR 406722/PR 415179) works, we can "delay start"
DrMemory's instrumentation. Wait for initialization to finish and then
do a memory, heap, and thread walk and start there. Won't catch bugs
that involve uninit memory from init time: but that's the tradeoff,
getting faster startup at cost of potential false neg. Once in
steady-state, for most apps our slowdowns should be better than
init slowdowns.
Original issue: http://code.google.com/p/drmemory/issues/detail?id=130
The text was updated successfully, but these errors were encountered: