Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1531463004:
[tracing]Fix resident size of malloc for mac and ios. (Closed)
|
Created:
5 years ago by ssid Modified:
5 years ago Reviewers:
Primiano Tucci (use gerrit) CC:
chromium-reviews, tracing+reviews_chromium.org, wfh+watch_chromium.org, vmpstr+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Description[tracing]Fix resident size of malloc for mac and ios.
The default system allocator works with 4 allocation regions:
tiny, small, large and huge.
The tiny and small region allocates large vm regions (1-8Mb) and for
each allocation the first continuous chunk that fits the allocation
size is returned. "max_size_in_use" gives the sum of sizes of the
regions without the last chunk that is untouched. So, any region in
this range should either be in use or was in use in the past and freed.
This would mean that this memory is resident (% the memory that client
allocated and not touched).
The large and huge regions maintain the hash table of exact allocation
sizes. So, "max_size_in_use" is the sum of allocated objects size,
which should be resident.
For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded
to 16 bytes and each allocation below 47Mb(small) is rounded to 512
bytes. Allocations larger than that are rounded to system page size.
This would cause the "max_size_in_use" to be more than the actual
resident size. But this is the closest approximation to resident size
and on experiments showed that the value at most 4% more than the
actual resident size.
The malloc dumps used to show resident size and allocated objects size.
It is hard to understand why is there a difference. This CL adds an
extra dump to specify what is that memory used for.
This CL also rearranges the #if conditions so that in future tcmalloc
is used in mac, it still shows correct values.
BUG=542584
Committed: https://crrev.com/86f78c1c70715d6f43ab59fa6cc51be4c1dc7774
Cr-Commit-Position: refs/heads/master@{#366366}
Patch Set 1 #Patch Set 2 : Additions. #
Total comments: 4
Patch Set 3 : fix comment. #Messages
Total messages: 18 (10 generated)
Description was changed from ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. BUG= ========== to ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. BUG=542584 ==========
ssid@chromium.org changed reviewers: + primiano@chromium.org
Description was changed from ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. BUG=542584 ========== to ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. The malloc dumps used to show resident size and allocated objects size. It is hard to understand why is there a difference. This CL adds an extra dump to specify what is that memory used for. This CL also rearranges the #if conditions so that in future tcmalloc is used in mac, it still shows correct values. BUG=542584 ==========
LGTM.thanks for the explanation https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... File base/trace_event/malloc_dump_provider.cc (right): https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... base/trace_event/malloc_dump_provider.cc:56: // the whole region other than the free bytes at the end of malloc magazines. magazines? https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... base/trace_event/malloc_dump_provider.cc:59: resident_size = stats.max_size_in_use; I'd add // See crrev.com/1531463004 for a detailed explanation.
Patchset #3 (id:40001) has been deleted
Done thanks. https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... File base/trace_event/malloc_dump_provider.cc (right): https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... base/trace_event/malloc_dump_provider.cc:56: // the whole region other than the free bytes at the end of malloc magazines. On 2015/12/18 14:54:24, Primiano Tucci wrote: > magazines? hm fixed. https://codereview.chromium.org/1531463004/diff/20001/base/trace_event/malloc... base/trace_event/malloc_dump_provider.cc:59: resident_size = stats.max_size_in_use; On 2015/12/18 14:54:24, Primiano Tucci wrote: > I'd add > // See crrev.com/1531463004 for a detailed explanation. Done.
The CQ bit was checked by ssid@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1531463004/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1531463004/60001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by ssid@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from primiano@chromium.org Link to the patchset: https://codereview.chromium.org/1531463004/#ps60001 (title: "fix comment.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1531463004/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1531463004/60001
Message was sent while issue was closed.
Description was changed from ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. The malloc dumps used to show resident size and allocated objects size. It is hard to understand why is there a difference. This CL adds an extra dump to specify what is that memory used for. This CL also rearranges the #if conditions so that in future tcmalloc is used in mac, it still shows correct values. BUG=542584 ========== to ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. The malloc dumps used to show resident size and allocated objects size. It is hard to understand why is there a difference. This CL adds an extra dump to specify what is that memory used for. This CL also rearranges the #if conditions so that in future tcmalloc is used in mac, it still shows correct values. BUG=542584 ==========
Message was sent while issue was closed.
Committed patchset #3 (id:60001)
Message was sent while issue was closed.
Description was changed from ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. The malloc dumps used to show resident size and allocated objects size. It is hard to understand why is there a difference. This CL adds an extra dump to specify what is that memory used for. This CL also rearranges the #if conditions so that in future tcmalloc is used in mac, it still shows correct values. BUG=542584 ========== to ========== [tracing]Fix resident size of malloc for mac and ios. The default system allocator works with 4 allocation regions: tiny, small, large and huge. The tiny and small region allocates large vm regions (1-8Mb) and for each allocation the first continuous chunk that fits the allocation size is returned. "max_size_in_use" gives the sum of sizes of the regions without the last chunk that is untouched. So, any region in this range should either be in use or was in use in the past and freed. This would mean that this memory is resident (% the memory that client allocated and not touched). The large and huge regions maintain the hash table of exact allocation sizes. So, "max_size_in_use" is the sum of allocated objects size, which should be resident. For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded to 16 bytes and each allocation below 47Mb(small) is rounded to 512 bytes. Allocations larger than that are rounded to system page size. This would cause the "max_size_in_use" to be more than the actual resident size. But this is the closest approximation to resident size and on experiments showed that the value at most 4% more than the actual resident size. The malloc dumps used to show resident size and allocated objects size. It is hard to understand why is there a difference. This CL adds an extra dump to specify what is that memory used for. This CL also rearranges the #if conditions so that in future tcmalloc is used in mac, it still shows correct values. BUG=542584 Committed: https://crrev.com/86f78c1c70715d6f43ab59fa6cc51be4c1dc7774 Cr-Commit-Position: refs/heads/master@{#366366} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/86f78c1c70715d6f43ab59fa6cc51be4c1dc7774 Cr-Commit-Position: refs/heads/master@{#366366} |
