1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
Future design considerations:
Instead of multiple switch statements, perhaps changing the allocation type
will change a set of function pointers. Because checking those allocation
types several times during an allocation is a performance problem.
The output object still needs to be implemented, along with classes and codes.
XML or an alternative output format to make interface with a gui would be
great. If nothing else, just codifying them would allow us to output them in a
more parsable fashion.
The stats object needs to be integrated and implemented, possibly extended.
Add the ability to easily ignore sections of code you don't want to have
memory statistics or leak info for. This could simply be an addition of a
dynamic_prefs flag.
We need someone to update the documentation to reflect the ability to change
allocation types with __nj_set_user_prefs.
The ability to release memory leak info and statistics at arbitrary points.
The release of memory leak info would not actually release any heap entries,
but only place a marker or hold an index value of where to start.
The ability to release all currently protected pages. Like mentioned above,
this would simply be a matter of writing an iterator function for
__nj_table_for_all_entries for the entry_pool object, and unmapping all
entries that were freed with CHK_FREE=error or segv. Calling this more than
once would be a problem though.
The ability to release all info on freed segments at arbitrary points. This is
not the same as above.. It could be used to purge the entry_pool table if
full or too large. I'm not sure why you would want to do this.
|
