After you are connected to the profiled application, find the Memory tab on the session panel.
Memory tab's section Memory & GC Telemetry shows the following graphs:
The telemetry information is remembered in a circular buffer in the profiler agent memory. This allows you to connect to a profiled application on demand and discover how the application behaved in the past.
The buffer capacity is 1 hour by default, and can be changed with the startup option telemetrylimit.
Classes view shows object counts by class. It is located in the Memory & GC Telemetry section of the Memory tab.
This view is available when the profiler is connected to a running application, allowing to instantly learn object counts without capturing and opening a memory snapshot.
This view is also available in performance snapshots, but is not available in memory snapshots being superseded with objects view.
The presented information can be useful as an overview of memory consumed by the profiled application and also as a clue to detecting memory leaks. For details, see How to find out why application eats that much memory? and How to find memory leaks?
This view, unlike other telemetry views, does not automatically periodically update. This is for performance considerations: gathering the statistics may take significant time in case of huge heaps with many objects, thus should run on demand.
Instead, it updates when:
Memory tab's section Allocations shows counts and sizes for objects whose allocations have been recorded, including objects which are still alive as well as objects that have been collected by the moment.
This live view provides only basic information, and you still need to capture memory snapshot to perform comprehensive analysis: to separate live objects from dead objects, to see where live objects are retained, etc.