DynamoRIO / DynamoRIO/dynamorio

Performance: Use all_memory_areas in more places on Linux

Open
#853 9 comments 0 reactions 0 assignees View on GitHub
Migrated Performance Priority-Medium Type-Feature
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

_From [rnk@google.com](https://code.google.com/u/rnk@google.com/) on July 25, 2012 11:16:26_

Profiling has shown proc maps parsing to be a hotspot, especially for apps that trigger faults with self-modifying code.

is_readable_without_exception in particular has this comment:
/\* FIXME case 9745: disabling all_memory_areas here since causing a ton
\* of asserts; re-enable once we're sure it truly matches the real
\* world
*/
I don't know how old this is. Re-enabling all_memory_areas here works for me on DRT, but it probably needs more testing. Do we know what apps had assertions when this comment was added? The comment comes from the initial svn commit.

----

get_stack_bounds() uses proc maps, but I think we can just use all mem there without too much risk. It also only gets called once per thread, it seems. Only a problem if lots of threads are launched at startup that do not very much work.

----

compute_memory_target() uses get_memory_info_from_os() _twice_! But it does so because it's called from our signal handler and can't acquire the lock that guards all_memory_areas.

Can we make all_memory_areas a lock free data structure, so we can read it from signal handlers? It might even have a side benefit of reducing contention in other usage situations.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=853_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.