Memory tracking

Generally, learning how to debug the memory helps developers determine what is causing the application to misbehave and fix memory issues. In order to assist the developers with this, Cohtml/Renoir provides options to allocate, track and debug the memory used by the plugin, which we will focus on in this post.

There are two types of allocations that the plugin uses: 

1. For GPU-created objects:  Objects such as different textures and buffers are stored by the plugin in the internal cache memory. Generally, Cohtml/Renoir tries to reduce the created GPU objects, but it’s not always possible to reuse already created resources with the default capacity of the internal caches. This can lead to the constant recreation of objects (such as textures). To help spot such issues, we have introduced in Chrome’s DevTools the ability to trace markers that mark when different GPU objects are created and destroyed. They are as follows:

• For textures - Texture Create/Destroy
• For Vertex Buffers - VB Create/Destroy
• For Index Buffers - IB Create/Destroy

The markers carry meta information regarding the created object, such as whether it’s a texture or a buffer and what types they are. Those markers can help detect abnormal behavior in the object’s creation and destruction. For example, if you observe using the creation/destruction markers that a texture is being created and destroyed in each frame, this could hint that the internal cache is too small:

2. Allocations that go through the IAllocator interface: The IAllocator is an interface used for observing and tracking all memory allocations (with the exception of the GPU resources) from the plugin, which are tagged for the developer to have access to the relative distribution of the memory among the subsystems. To track the memory allocations, you can override the methods (Allocate/Reallocate/Deallocate/VirtualAllocate/VirtualFree/AlignedAllocate/etc. methods.) in the interface and add memory counting. The below example shows how this is done for the IAllocator::Allocate method:

An example implementation of the memory tracking of the different tags can be found in this link (click here). The MemoryTracker override of the IAllocator interface counts the number of allocations per type and the total allocated memory.

The other methods that let you keep track of the memory would be the ones for the internal caches, which are the `View::GetCacheCountStats` and `View::GetCacheBytesStats` functions. The types of caches that can be passed to these methods are in the `cohtml::InternalCaches enum`:

• ICACHE_Shadows - Access the cache for shadow textures (e.g., box-shadow, text-shadow). Obtained using View::GetCacheCountStats​​;
• ICACHE_Paths - Access the cache for complex shapes. Obtained using View::GetCacheCountStats​​;
• ICACHE_Textures - Access the cache for client textures (such as image elements) Obtained using View::GetCacheByteStats​ and View::GetCacheCountStats​;
• ICACHE_ScratchLayers - Access the cache for temporary internal textures containing packed data from multiple surfaces. Obtained using View::GetCacheByteStats​;
• ICACHE_ScratchTextures - Access the cache for temporary internal textures dedicated to single surfaces only. Obtained using View::GetCacheByteStats​;
• ICACHE_GfxCommandBuffers - Access the pool of command buffers used for generating graphics commands for the graphics library. The cache has both size in number of contained objects and size in bytes.
• ICACHE_GfxCommandProcessors - Access the pool of command processors used for transforming the raw command buffers into ones usable by the graphics backend. The reported size in bytes is for resident memory only, as the memory allocated by dedicated per-frame allocators is excluded.

Aside from the caches, you can pull the images currently used by the UI using the` cohtml::System::GetSystemCacheStats` method. An example of this method can be found in our sample project in the ‘CohtmlApplication.cpp’:

On a related note, Cohtml/Renoir enhances the application's performance is by reusing already allocated memory at the cost of some memory overhead. If you wish to reduce the overall memory footprint at the cost of impacting the performance, you can set the `EnableInternalAllocator` member of the  `cohtml::LibraryParams` to false.