{"push_id":655731059,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"36be9f132551f83cfb8485c42a12be075689425c","before":"609f3286449234db42743d3c79ea30db60bf7838","commits":[{"sha":"56ad426b405cd7fb3c49c4c061257dbc2614a73f","author":{"email":"b3066f53d7a0fd3eaa1b657a44ad0856312d2203@users.noreply.github.com","name":"Greg Titus"},"message":"Default to not track mem desc types not directly related to Chapel code.\n\nChange the default memtrack status for runtime-oriented memory desc\ntypes that only have a loose relationship (especially an asynchronous\nrelationship) with Chapel program constructs.  Basically these are low\nlevel buffers, flags, remote fork argument copies, and other comm info\nblocks in the comm layer implementation, and task descriptors and other\nmeta-information having to do with task management in the tasking layer\nimplementation.  For the most part these are allocated synchronously as\nexecution encounters the corresponding Chapel program constructs (remote\ncommunication events and tasking statements), but they may be freed\nasynchronously with the end of execution of those constructs.\n\nThis improves the usefulness of memory tracking reporting, especially\nwhen that is done in the middle of execution rather than at the end.  In\nturn this reduces variability in memory tracking in nightly testing,\nhelping to resolve https://chapel.atlassian.net/browse/CHAPEL-8.\n\nThere was a choice here between continuing to track such memory descs\nand just not reporting them, or not tracking them in the first place.\nTracking but not reporting would allow them to continue to affect the\ncurrent memory allocated and high-water mark values, but would create\n(more of) a mismatch between the current memory allocated value and the\ntotal of the by-type memory report, since they wouldn't appear in the\nlatter.  I chose instead to not track them at all, which makes the\ncurrent and high-water memory allocation values less accurate (because\nthe memory is still allocated even though it's not tracked) but removes\nthe tracking overhead.  It would not be much work to change to tracking\nbut not reporting if this is desired instead.","distinct":true,"url":"https://api.github.com/repos/Kyle-B/chapel/commits/56ad426b405cd7fb3c49c4c061257dbc2614a73f"},{"sha":"36be9f132551f83cfb8485c42a12be075689425c","author":{"email":"b3066f53d7a0fd3eaa1b657a44ad0856312d2203@users.noreply.github.com","name":"Greg Titus"},"message":"Merge pull request #1931 from gbtitus/memtrack-turn-off-internals\n\nDefault to not track mem desc types not directly related to Chapel code.\r\n\r\nChange the default memtrack status for runtime-oriented memory desc\r\ntypes that only have a loose relationship (especially an asynchronous\r\nrelationship) with Chapel program constructs. Basically these are low\r\nlevel buffers, flags, remote fork argument copies, and other comm info\r\nblocks in the comm layer implementation, and task descriptors and other\r\nmeta-information having to do with task management in the tasking layer\r\nimplementation. For the most part these are allocated synchronously as\r\nexecution encounters the corresponding Chapel program constructs (remote\r\ncommunication events and tasking statements), but they may be freed\r\nasynchronously with the end of execution of those constructs.\r\n\r\nThis improves the usefulness of memory tracking reporting, especially\r\nwhen that is done in the middle of execution rather than at the end. In\r\nturn this reduces variability in memory tracking in nightly testing,\r\nhelping to resolve https://chapel.atlassian.net/browse/CHAPEL-8.\r\n\r\nThere was a choice here between continuing to track such memory descs\r\nand just not reporting them, or not tracking them in the first place.\r\nTracking but not reporting would allow them to continue to affect the\r\ncurrent memory allocated and high-water mark values, but would create\r\n(more of) a mismatch between the current memory allocated value and the\r\ntotal of the by-type memory report, since they wouldn't appear in the\r\nlatter. I chose instead to not track them at all, which makes the\r\ncurrent and high-water memory allocation values less accurate (because\r\nthe memory is still allocated even though it's not tracked) but removes\r\nthe tracking overhead. It would not be much work to change to tracking\r\nbut not reporting if this is desired instead.\r\n\r\nReviewed by @hildeth .","distinct":true,"url":"https://api.github.com/repos/Kyle-B/chapel/commits/36be9f132551f83cfb8485c42a12be075689425c"}]}