{"action":"opened","issue":{"url":"https://api.github.com/repos/jemalloc/jemalloc/issues/1265","repository_url":"https://api.github.com/repos/jemalloc/jemalloc","labels_url":"https://api.github.com/repos/jemalloc/jemalloc/issues/1265/labels{/name}","comments_url":"https://api.github.com/repos/jemalloc/jemalloc/issues/1265/comments","events_url":"https://api.github.com/repos/jemalloc/jemalloc/issues/1265/events","html_url":"https://github.com/jemalloc/jemalloc/issues/1265","id":336732124,"node_id":"MDU6SXNzdWUzMzY3MzIxMjQ=","number":1265,"title":"Proposal: `mallctl` option for continuous dumping of profiled allocations","user":{"login":"tyleretzel","id":6255201,"node_id":"MDQ6VXNlcjYyNTUyMDE=","avatar_url":"https://avatars3.githubusercontent.com/u/6255201?v=4","gravatar_id":"","url":"https://api.github.com/users/tyleretzel","html_url":"https://github.com/tyleretzel","followers_url":"https://api.github.com/users/tyleretzel/followers","following_url":"https://api.github.com/users/tyleretzel/following{/other_user}","gists_url":"https://api.github.com/users/tyleretzel/gists{/gist_id}","starred_url":"https://api.github.com/users/tyleretzel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tyleretzel/subscriptions","organizations_url":"https://api.github.com/users/tyleretzel/orgs","repos_url":"https://api.github.com/users/tyleretzel/repos","events_url":"https://api.github.com/users/tyleretzel/events{/privacy}","received_events_url":"https://api.github.com/users/tyleretzel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-06-28T18:31:46Z","updated_at":"2018-06-28T18:31:46Z","closed_at":null,"author_association":"NONE","body":"There are some opportunities in profiling that don't fit into the current model for profiling. As of now, profiling keeps track of allocated memory that hasn't been freed, and entirely forgets about allocations that have been freed (ignoring `opt.prof_accum`). This is nice because it allows profiling to be on all the time without runaway memory usage, but it's not useful if the information you want to collect talks about when/how an object is freed. Two potentially useful sorts of data in this category are:\r\n\r\na) data about allocation lifetimes (#1149): we could see the average lifetime for an allocation site (e.g. in nanoseconds), and we could also see the set of stack traces where allocations from a particular allocation site are freed.\r\n\r\nb) data about threads: we could see if allocations from a particular allocation site are often allocated on one thread and freed on a different thread.\r\n\r\nOne easy way to collect this data is to just dump all sampled allocations to a log, and then parse out this information in another program. This would be something that can be turned on and off via `mallctl`.\r\n\r\nTo be concrete, each allocation would be appended to a dump file when it is freed, so the dump file would be a list of these allocations with appropriate metadata. This could be e.g. json or some binary format, but we should include at least the following information\r\n\r\n- Size\r\n- Timestamp for `malloc` call\r\n- Timestamp for `free` call\r\n- Stack trace for `malloc` call\r\n- Stack trace for `free` call\r\n- Thread id/name for `malloc` call\r\n\r\n\r\n"}}
{"actor":{"display_login":"tyleretzel"}}