From: Andrey Kvochko Date: Fri, 22 Sep 2017 14:46:45 +0000 (+0300) Subject: Address latest feedback X-Git-Tag: submit/tizen/20180620.112952^2~25^2~1 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=dbcf906fbec19fbc00003ee9532855af53113b37;p=sdk%2Ftools%2Fheaptrack.git Address latest feedback --- diff --git a/README.md b/README.md index e49103d..4eec8d7 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,10 @@ -## CoreCLR Memory Profiling +# CoreCLR Memory Profiling -(Original KDE Heaptrack's README can be found [here](HEAPTRACK_README.md) ) +(Original KDE Heaptrack's README can be found [here](docs/HEAPTRACK_README.md)) -### Brief contents of the Guide +## Brief contents of the Guide -#### VM [[Details]](#download-and-unpack-vm-disk-image-from-this-page) +### VM [[Details]](docs/DETAILED.md#download-and-unpack-vm-disk-image-from-this-page) 1\. Download and unpack VM image, start it in VirtualBox and connect with Tizen device @@ -16,7 +16,7 @@ cat ubuntu-17.04.vdi.tar.bz2-* | tar xjvf - -For unpacking on Windows, please see [the details](#download-and-unpack-vm-disk-image-from-this-page). +For unpacking on Windows, please see [the details](docs/DETAILED.md#download-and-unpack-vm-disk-image-from-this-page). * [ubuntu-17.04.vdi.tar.bz2-31-08-17-aa](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/ubuntu-17.04.vdi.tar.bz2-31-08-17-aa?api=v2) * [ubuntu-17.04.vdi.tar.bz2-31-08-17-ab](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/ubuntu-17.04.vdi.tar.bz2-31-08-17-ab?api=v2) @@ -30,7 +30,7 @@ For unpacking on Windows, please see [the details](#download-and-unpack-vm-disk- [[SHA256 values for archive contents]](#checksums) -#### Initialization of device for measurements [[Details]](#prepare-tizen-device-for-measurements) +### Initialization of device for measurements [[Details]](docs/DETAILED.md#prepare-tizen-device-for-measurements) 2\. Put Tizen RPMs to VM's /home/ubuntu/device-rpms for: - debuginfo packages @@ -40,7 +40,7 @@ For unpacking on Windows, please see [the details](#download-and-unpack-vm-disk- [Video tutorial](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/How-to-prepare-Tizen-device-for-measurements.mp4?api=v2) -#### Build profiler module for your CoreCLR version [[Details]](#build-profiler-module-for-your-coreclr-version) +### Build profiler module for your CoreCLR version [[Details]](docs/DETAILED.md#build-profiler-module-for-your-coreclr-version) By default the libprofiler.so is already built for coreclr-2.0.0.11992-11.1.armv7l, so if you use this version, then you don't need to rebuild it. @@ -49,7 +49,7 @@ For details, see "Build profiler module" in full contents below (section 5) [Video tutorial](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/How-to-build-managed-profiling-module.mp4?api=v2) -#### Measurements [[Details]](#run-measurements) +### Measurements [[Details]](docs/DETAILED.md#run-measurements) 8\. Make sure that "debuginfo" packages are installed for all libraries that you want to track by the profiler @@ -75,158 +75,6 @@ The GUI will start separately for **Malloc** part, **Managed** part, **mmap Priv [[Solutions for possible issues]](#troubleshooting) -### Detailed Guide - -To perform the measurements the following steps are necessary: - -#### Download and unpack VM disk image from this page - -The VM contains scripts and tools to prepare Tizen device for measurements, and to perform the measurements. - -The disk image is archived and split into several files. - -To unpack it, please, download all the files to separate directory and: - -* on Linux run the following command in the directory: - -``` -cat ubuntu-17.04.vdi.tar.bz2-* | tar xjvf - -``` - -* on Windows run the following command in the directory and unpack the created ubuntu-17.04.vdi.tar.bz2 using some archiver (for example, 7-zip from [7-zip.org](http://7-zip.org/)): - -``` -copy /B ubuntu-17.04.vdi.tar.bz2-31-08-17-aa + ubuntu-17.04.vdi.tar.bz2-31-08-17-ab + ubuntu-17.04.vdi.tar.bz2-31-08-17-ac + ubuntu-17.04.vdi.tar.bz2-31-08-17-ad + ubuntu-17.04.vdi.tar.bz2-31-08-17-ae + ubuntu-17.04.vdi.tar.bz2-31-08-17-af + ubuntu-17.04.vdi.tar.bz2-31-08-17-ag + ubuntu-17.04.vdi.tar.bz2-31-08-17-ah + ubuntu-17.04.vdi.tar.bz2-31-08-17-ai ubuntu-17.04.vdi.tar.bz2 -``` - - -The unpacked VM image has the following checksums: - -``` -ubuntu-17.04.vdi sha256sum 1afcea540149f76fae6e243839b6a21666725cc1409b4c259be82533e2a21a24 -``` - -The checksum can be checked using `sha256sum ubuntu-17.04.vdi` on Linux, and using 7-zip (right-click file -> CRC -> SHA256) on Windows - -#### Create an Ubuntu-64 VirtualBox VM based on this disk image and run it. - -The VM image was tested using VirtualBox 5.1.26 on Linux. -Login is ubuntu, and password is the same - ubuntu. - -How to create VM: - -1. Run VirtualBox -2. Click 'New' -3. Enter a VM name, like 'CoreCLR Memory Profiling Tool' -4. Choose Type: 'Linux' -5. Choose Version: 'Ubuntu (64-bit)' -6. Click 'Next' -7. Choose memory size (at least 2048 MB) -8. Click 'Next' -9. Choose 'Use an existing virtual hard disk file' -10. Click the 'Open File' graphical button next to ComboBox element. This will open dialog for choosing ubuntu-17.04.vdi (find and choose the file) -11. Click 'Create' -12. Double-click the VM name in list of VMs to start it - -Minimal requirements: 2048 MB memory, 1 CPU core -Recommended: 8192 MB memory, 4 CPU core - -Other settings (network, devices, etc.): USB should be enabled to connect Tizen device through sdb - -#### Connect your Tizen device through USB connection and attach it to the VirtualBox - -Use the following menu of VirtualBox: Devices -> USB -> Samsung TIZEN device - -#### Prepare Tizen device for measurements - -To make measurements possible, the device additionally to default packages, which are necessary to run .NET applications, should contain: - -* "debuginfo" RPMs (debug information) for libraries, which are used in the .NET applications, like coreclr, etc. - -Please, make sure that versions of the RPMs equal to versions of the corresponding libraries. - -If debug package is missing or can't be decoded, the corresponding functions in measurements report will be labelled `` - -"debugsource" RPMs are not necessary. - -To prepare device for measurements the script can be used: - -``` -/home/ubuntu/heaptrack-scripts/prepare-device.sh -``` - - -Before starting the script, please, make sure to put all the necessary RPM packages to **/home/ubuntu/device-rpms** in the VM. -Please, choose the versions of the binary and debuginfo packages for your device corresponding to each other ("debuginfo" for same versions, as binary packages). - -For example, if you flash [http://download.tizen.org/snapshots/tizen/unified/latest/](http://download.tizen.org/snapshots/tizen/unified/latest/) to your Tizen device, -then you need debuginfo packages from [http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/](http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/) -At least, the following debuginfo packages are highly recommended: -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/coreclr-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/ecore-[...]-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/edje-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/eet-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/eina-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/elementary-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/security-manager-debuginfo-[...].armv7l.rpm -- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/capi-[...]-debuginfo-[...].armv7l.rpm - -The prepare-device.sh script will install the packages to device, and also make changes as implemented in /home/ubuntu/heaptrack-scripts/prepare-device-internal.sh script to remount root file system into read-write mode, and to move some directories from rootfs to /opt/usr to free some disk space on rootfs for installation of other packages. - -Please, use the script only once - don't run it second time until the device is reset to its initial state. - -To make sure the device was prepared correctly, please, check the following: -- /usr/share/dotnet directory is moved to /opt/usr/dotnet -- /usr/shared/dotnet.tizen is moved to /opt/usr/dotnet.tizen -- /usr/lib/debug is moved to /opt/usr/lib/debug -- `ls -Z` shows "_" smack attribute for all contents of the three directories -- there are symlinks created for the directories to their initial locations (i.e. /usr/share/dotnet symlink to /opt/usr/dotnet etc.) -- `rpm -qa | grep debuginfo` shows all the debuginfo packages that you planned to install - -#### Build profiler module for your CoreCLR version - -By default the libprofiler.so is already built for coreclr-2.0.0.11992-11.1.armv7l, so if you use this version, -then you don't need to rebuild it. - -**WARNING:** - -**If the libprofiler.so doesn't match the CoreCLR version, then managed memory and managed call stacks will not be profiled.** - -1. Find out version of CoreCLR package on your Tizen device, like coreclr-2.0.0.11992-11.1.armv7l -2. Download corresponding "devel" package, like coreclr-devel-2.0.0.11992-11.1.armv7l.rpm -3. Use the "devel" package to build profiler module (on armel system or under armel rootfs), using contents of the directory from the VM: - 1. /home/ubuntu/heaptrack-common/build-profiler-armel (see build.sh in the directory) -4. Put the compiled libprofiler.so (build-profiler-armel/build/src/libprofiler.so) module to /home/ubuntu/heaptrack-common/build-armel/libprofiler.so - -#### Run measurements - -Setup completed! Now, we can run memory consumption measurements. - -**Note: This way of measurements assumes that .NET application starts based on dotnet-launcher.** - -To start measurements, run application (application will start and works as usual, although noticeably/significantly (30x to 100x) slower because of profiling) - -``` -/home/ubuntu/heaptrack-scripts/heaptrack.sh [application ID] [application path] -``` - -like the following: - -``` - ./heaptrack-scripts/heaptrack.sh org.tizen.example.HelloWorld.Tizen /opt/usr/home/owner/apps_rw/HelloWorld.Tizen/bin/HelloWorld.Tizen.exe -``` - - -After this, at any moment, you can stop application to get the memory profiling results for the moment of stopping. -To stop and get profiling results, press "c". - -Upon stop, application is terminated, and profiling results are downloaded to VM. -When profiling results are downloaded, the measurements report is shown in GUI viewer. - -The GUI will start separately for Malloc part, Managed part, mmap Private_Dirty part, mmap Private_Clean part and mmap Shared_Clean part. - -Each part will be opened after the previous is closed. - ### Profiling results The GUI viewer provides several views for the profiling results. @@ -237,7 +85,7 @@ The GUI viewer provides several views for the profiling results. - The "leaks" in the interface are most probably not actual leaks - it is label for memory that wasn't freed when application was terminating. However, it is usual behaviour for many libraries, including CoreCLR to not free memory upon application termination, as kernel anyway frees it. So, "leaks" labels should be considered as labels for memory, which was consumed just before memory profiling stopped. -##### Summary view +#### Summary view Peak contributions shows top functions that consumed memory at moment of highest memory consumption. Peak instances shows top functions that has most memory items allocated and not freed at moment of highest count of the memory items. Largest memory leaks - top functions that allocated memory, which wasn't deallocated up to moment of memory profiling stop. @@ -245,24 +93,24 @@ Most memory allocations - top functions that call allocation most number of time Most temporary allocations - the same for allocations, in which deallocation is called very close to allocation, like `p = malloc(...); simple code; free (p)`. Most memory allocated - top functions, which allocated most memory (this doesn't account deallocations, so is not very useful for analysis of memory consumption causes). -##### Bottom-Up/Top-Down view +#### Bottom-Up/Top-Down view Memory consumption details for each detected call stack. -##### Caller / Callee view +#### Caller / Callee view Memory consumption statistics for each function for itself, and also inclusive (i.e. including statistics of other functions, which it called). -##### Flame Graph view +#### Flame Graph view Also represents memory consumption per call-stack (either top-down or bottom-down mode) Combobox allows to choose between different statistics (like in Summary view). The "leaks" here also are not the memory leaks: it is memory that was consumed at moment of profiling stop. So, the "leaks" view seems to be the most useful to investigate memory consumption details. -##### Other +#### Other Next several views are graphs for different memory consumption statistics (also, like in Summary view), as they change in time of application execution. Here, the "consumed" is used instead of "leaks", which is more precise. The "consumed" view shows memory consumption graph for top memory consuming function (separately, as shown in color, and also total consumption - the topmost graph). -### Troubleshooting +## Troubleshooting 1\. The heaptrack is built for one of latest Tizen Unified TM1 system. If it can't be started on your Tizen device, because of missing dependencies, please recompile it from sources (see /home/ubuntu/heaptrack-common/build-armel). @@ -270,54 +118,54 @@ Recompilation is simple, like "mkdir build_dir; cd build_dir; cmake ..; make -j4 2\. Managed memory consumption or managed call stacks data is missing -See [[Build profiler module]](#build-profiler-module-for-your-coreclr-version) +See [[Build profiler module]](docs/DETAILED.md#build-profiler-module-for-your-coreclr-version) 3\. Please, feel free to ask any questions, in case of the described or other issues ([https://github.sec.samsung.net/dotnet/profiler/issues/4](https://github.sec.samsung.net/dotnet/profiler/issues/4)) The profiling tool can show memory consumption of **Managed**, **Malloc** and **Mmap**-allocated regions. -### Screenshots +## Screenshots -#### malloc'ed memory over time -![malloc-Consumed-Graph.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/malloc-Consumed-Graph.png?api=v2) +### malloc'ed memory over time +![malloc-Consumed-Graph.png](screenshots/malloc-Consumed-Graph.png) * Each color shows different function (function name is shown when mouse is over a part of graph) * The top part is sum of all malloc-allocated memory (for all allocating functions) * The graph is useful to get overall picture of how memory consumption changed as program executed -#### Functions and their statistics -![malloc-Plain-Statistics.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/malloc-Plain-Statistics.png?api=v2) +### Functions and their statistics +![malloc-Plain-Statistics.png](screenshots/malloc-Plain-Statistics.png) * Peak is memory consumption of particular function at overall maximum of application consumption (this considers only currently shown memory - i.e. only malloc, or mmap Private_Dirty, or mmap Private_Clean, etc.) * Leaked is memory consumption just at application exit (not actually, leak, as most application do not free memory at their exit - so, it is just information about memory consumption just before application exit) * Allocated is sum of all allocated memory sizes (doesn't account that some memory was already freed - counts only allocations) * "Incl." mark is for the function and all functions that it calls; "Self" mark is for the function only -#### Call stacks and memory consumption at each point of call stack -![malloc-FlameGraph-Details.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/malloc-FlameGraph-Details.png?api=v2) +### Call stacks and memory consumption at each point of call stack +![malloc-FlameGraph-Details.png](screenshots/malloc-FlameGraph-Details.png) * For example, "icu::Normalizer2Impl::ensureCanonIterData" calls "utrie2_enum" and "icu::CanonIterData::CanonIterData" and "utri2_freeze" * The "utrie2_enum" and "icu::CanonIterData::CanonIterData" and "utri2_freeze" call other functions that in sum allocate 539, 283 and 80 kilobytes, correspondingly * The consumption for "ensureCanonIterData" will be shown as 904 kB - it is sum of the three values * In another places (another call stacks) the functions can also be called and that memory consumption will be accounted separately for these and those call stacks -#### Reversed FlameGraph (if "Bottom-Down View" is checked) -![malloc-FlameGraph-Reversed.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/malloc-FlameGraph-Reversed.png?api=v2) +### Reversed FlameGraph (if "Bottom-Down View" is checked) +![malloc-FlameGraph-Reversed.png](screenshots/malloc-FlameGraph-Reversed.png) * A useful form of FlameGraph to show the call stacks reversed * So, the bottom line will show the allocator functions - like malloc, calloc, realloc, etc. and lines above will be the functions that call the allocator functions -#### Top-N lists of functions: -![malloc-Summary.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/malloc-Summary.png?api=v2) +### Top-N lists of functions: +![malloc-Summary.png](screenshots/malloc-Summary.png) * functions that consumed most when peak of malloc memory consumption occured ("peak contributions") * functions that consumed most just before application exit ("largest memory leaks") * functions that called allocators more than others ("most memory allocations") * functions that called allocators more than others for temporary allocations ("most temporary allocations") - temporary is the case when malloc and free are called almost one after other (with no allocations between them) * functions that allocated most memory at sum ("most memory allocated") - just sum of allocations, without accounting freeing of memory * "peak RSS" is currently experimental and so is not precise -#### Managed heap inspection -![managed-ReferenceTree.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/managed-ReferenceTree.png?api=v2) +### Managed heap inspection +![managed-ReferenceTree.png](screenshots/managed-ReferenceTree.png) * Objects are grouped by their type * If type T2 is a child of type T1, it means that objects of type T2 reference objects of type T1 * Shallow Size is the total size of objects in the reference chain * Referenced Size is the size of objects referenced by the parent object. For example, Xamarin.Forms.ResourceDictionary indirectly references 252 bytes of System.Strings in the screenshot -#### mmap-allocated memory graphs +### mmap-allocated memory graphs Most of the graphs listed above are also available for mmap-allocated memory. -* ![mmap-private-dirty-Plain-Statistics.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/mmap-private-dirty-Plain-Statistics.png?api=v2) -* ![mmap-private-dirty-Consumed-Graph.png](http://suprem.sec.samsung.net/confluence/download/attachments/81831470/mmap-private-dirty-Consumed-Graph.png?api=v2) +* ![mmap-private-dirty-Plain-Statistics.png](screenshots/mmap-private-dirty-Plain-Statistics.png) +* ![mmap-private-dirty-Consumed-Graph.png](screenshots/mmap-private-dirty-Consumed-Graph.png) * the mmap-allocated memory is divided into four groups (as in /proc/.../smaps): Private_Dirty, Private_Clean, Shared_Clean + Shared_Dirty * Private_Dirty is process-local (not shared) memory that was modified by the process * Private_Clean is process-local (not shared) memory that was loaded from disk and not modified by the process @@ -331,7 +179,7 @@ Most of the graphs listed above are also available for mmap-allocated memory. * overhead of profiler * possibly, other allocators if they use `sbrk` (this is unusual) -### Checksums +## Checksums SHA256SUM for unpacked VM image diff --git a/docs/DETAILED.md b/docs/DETAILED.md new file mode 100644 index 0000000..bba0fbc --- /dev/null +++ b/docs/DETAILED.md @@ -0,0 +1,152 @@ +# Detailed Guide + +To perform the measurements the following steps are necessary: + +## Download and unpack VM disk image from this page + +The VM contains scripts and tools to prepare Tizen device for measurements, and to perform the measurements. + +The disk image is archived and split into several files. + +To unpack it, please, download all the files to separate directory and: + +* on Linux run the following command in the directory: + +``` +cat ubuntu-17.04.vdi.tar.bz2-* | tar xjvf - +``` + +* on Windows run the following command in the directory and unpack the created ubuntu-17.04.vdi.tar.bz2 using some archiver (for example, 7-zip from [7-zip.org](http://7-zip.org/)): + +``` +copy /B ubuntu-17.04.vdi.tar.bz2-31-08-17-aa + ubuntu-17.04.vdi.tar.bz2-31-08-17-ab + ubuntu-17.04.vdi.tar.bz2-31-08-17-ac + ubuntu-17.04.vdi.tar.bz2-31-08-17-ad + ubuntu-17.04.vdi.tar.bz2-31-08-17-ae + ubuntu-17.04.vdi.tar.bz2-31-08-17-af + ubuntu-17.04.vdi.tar.bz2-31-08-17-ag + ubuntu-17.04.vdi.tar.bz2-31-08-17-ah + ubuntu-17.04.vdi.tar.bz2-31-08-17-ai ubuntu-17.04.vdi.tar.bz2 +``` + + +The unpacked VM image has the following checksums: + +``` +ubuntu-17.04.vdi sha256sum 1afcea540149f76fae6e243839b6a21666725cc1409b4c259be82533e2a21a24 +``` + +The checksum can be checked using `sha256sum ubuntu-17.04.vdi` on Linux, and using 7-zip (right-click file -> CRC -> SHA256) on Windows + +## Create an Ubuntu-64 VirtualBox VM based on this disk image and run it. + +The VM image was tested using VirtualBox 5.1.26 on Linux. +Login is ubuntu, and password is the same - ubuntu. + +How to create VM: + +1. Run VirtualBox +2. Click 'New' +3. Enter a VM name, like 'CoreCLR Memory Profiling Tool' +4. Choose Type: 'Linux' +5. Choose Version: 'Ubuntu (64-bit)' +6. Click 'Next' +7. Choose memory size (at least 2048 MB) +8. Click 'Next' +9. Choose 'Use an existing virtual hard disk file' +10. Click the 'Open File' graphical button next to ComboBox element. This will open dialog for choosing ubuntu-17.04.vdi (find and choose the file) +11. Click 'Create' +12. Double-click the VM name in list of VMs to start it + +Minimal requirements: 2048 MB memory, 1 CPU core. + +Recommended: 8192 MB memory, 4 CPU core. + +Other settings (network, devices, etc.): USB should be enabled to connect Tizen device through sdb + +## Connect your Tizen device through USB connection and attach it to the VirtualBox + +Use the following menu of VirtualBox: Devices -> USB -> Samsung TIZEN device + +## Prepare Tizen device for measurements + +To make measurements possible, the device additionally to default packages, which are necessary to run .NET applications, should contain: + +* "debuginfo" RPMs (debug information) for libraries, which are used in the .NET applications, like coreclr, etc. + +Please, make sure that versions of the RPMs equal to versions of the corresponding libraries. + +If debug package is missing or can't be decoded, the corresponding functions in measurements report will be labelled `` + +"debugsource" RPMs are not necessary. + +To prepare device for measurements the script can be used: + +``` +/home/ubuntu/heaptrack-scripts/prepare-device.sh +``` + + +Before starting the script, please, make sure to put all the necessary RPM packages to **/home/ubuntu/device-rpms** in the VM. +Please, choose the versions of the binary and debuginfo packages for your device corresponding to each other ("debuginfo" for same versions, as binary packages). + +For example, if you flash [http://download.tizen.org/snapshots/tizen/unified/latest/](http://download.tizen.org/snapshots/tizen/unified/latest/) to your Tizen device, +then you need debuginfo packages from [http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/](http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/) +At least, the following debuginfo packages are highly recommended: +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/coreclr-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/ecore-[...]-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/edje-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/eet-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/eina-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/elementary-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/security-manager-debuginfo-[...].armv7l.rpm +- http://download.tizen.org/snapshots/tizen/unified/latest/repos/standard/debug/capi-[...]-debuginfo-[...].armv7l.rpm + +The prepare-device.sh script will install the packages to device, and also make changes as implemented in /home/ubuntu/heaptrack-scripts/prepare-device-internal.sh script to remount root file system into read-write mode, and to move some directories from rootfs to /opt/usr to free some disk space on rootfs for installation of other packages. + +Please, use the script only once - don't run it second time until the device is reset to its initial state. + +To make sure the device was prepared correctly, please, check the following: +- /usr/share/dotnet directory is moved to /opt/usr/dotnet +- /usr/shared/dotnet.tizen is moved to /opt/usr/dotnet.tizen +- /usr/lib/debug is moved to /opt/usr/lib/debug +- `ls -Z` shows "_" smack attribute for all contents of the three directories +- there are symlinks created for the directories to their initial locations (i.e. /usr/share/dotnet symlink to /opt/usr/dotnet etc.) +- `rpm -qa | grep debuginfo` shows all the debuginfo packages that you planned to install + +## Build profiler module for your CoreCLR version + +By default the libprofiler.so is already built for coreclr-2.0.0.11992-11.1.armv7l, so if you use this version, +then you don't need to rebuild it. + +**WARNING:** + +**If the libprofiler.so doesn't match the CoreCLR version, then managed memory and managed call stacks will not be profiled.** + +1. Find out version of CoreCLR package on your Tizen device, like coreclr-2.0.0.11992-11.1.armv7l +2. Download corresponding "devel" package, like coreclr-devel-2.0.0.11992-11.1.armv7l.rpm +3. Use the "devel" package to build profiler module (on armel system or under armel rootfs), using contents of the directory from the VM: + 1. /home/ubuntu/heaptrack-common/build-profiler-armel (see build.sh in the directory) +4. Put the compiled libprofiler.so (build-profiler-armel/build/src/libprofiler.so) module to /home/ubuntu/heaptrack-common/build-armel/libprofiler.so + +## Run measurements + +Setup completed! Now, we can run memory consumption measurements. + +**Note: This way of measurements assumes that .NET application starts based on dotnet-launcher.** + +To start measurements, run application (application will start and works as usual, although noticeably/significantly (30x to 100x) slower because of profiling) + +``` +/home/ubuntu/heaptrack-scripts/heaptrack.sh [application ID] [application path] +``` + +like the following: + +``` + ./heaptrack-scripts/heaptrack.sh org.tizen.example.HelloWorld.Tizen /opt/usr/home/owner/apps_rw/HelloWorld.Tizen/bin/HelloWorld.Tizen.exe +``` + + +After this, at any moment, you can stop application to get the memory profiling results for the moment of stopping. +To stop and get profiling results, press "c". + +Upon stop, application is terminated, and profiling results are downloaded to VM. +When profiling results are downloaded, the measurements report is shown in GUI viewer. + +The GUI will start separately for Malloc part, Managed part, mmap Private_Dirty part, mmap Private_Clean part and mmap Shared_Clean part. + +Each part will be opened after the previous is closed. diff --git a/HEAPTRACK_README.md b/docs/HEAPTRACK_README.md similarity index 100% rename from HEAPTRACK_README.md rename to docs/HEAPTRACK_README.md diff --git a/screenshots/malloc-Consumed-Graph.png b/screenshots/malloc-Consumed-Graph.png new file mode 100644 index 0000000..3939e94 Binary files /dev/null and b/screenshots/malloc-Consumed-Graph.png differ diff --git a/screenshots/malloc-FlameGraph-Details.png b/screenshots/malloc-FlameGraph-Details.png new file mode 100644 index 0000000..65be7e8 Binary files /dev/null and b/screenshots/malloc-FlameGraph-Details.png differ diff --git a/screenshots/malloc-FlameGraph-Reversed.png b/screenshots/malloc-FlameGraph-Reversed.png new file mode 100644 index 0000000..8915652 Binary files /dev/null and b/screenshots/malloc-FlameGraph-Reversed.png differ diff --git a/screenshots/malloc-Plain-Statistics.png b/screenshots/malloc-Plain-Statistics.png new file mode 100644 index 0000000..58a188c Binary files /dev/null and b/screenshots/malloc-Plain-Statistics.png differ diff --git a/screenshots/malloc-Summary.png b/screenshots/malloc-Summary.png new file mode 100644 index 0000000..e43795d Binary files /dev/null and b/screenshots/malloc-Summary.png differ diff --git a/screenshots/managed-ReferenceTree.png b/screenshots/managed-ReferenceTree.png new file mode 100644 index 0000000..5b234b8 Binary files /dev/null and b/screenshots/managed-ReferenceTree.png differ diff --git a/screenshots/mmap-private-dirty-Consumed-Graph.png b/screenshots/mmap-private-dirty-Consumed-Graph.png new file mode 100644 index 0000000..5503c83 Binary files /dev/null and b/screenshots/mmap-private-dirty-Consumed-Graph.png differ diff --git a/screenshots/mmap-private-dirty-Plain-Statistics.png b/screenshots/mmap-private-dirty-Plain-Statistics.png new file mode 100644 index 0000000..a929c46 Binary files /dev/null and b/screenshots/mmap-private-dirty-Plain-Statistics.png differ