hi hello welome and welcome to the third episode of visual VM profiler episode videos so previously in our first two videos we have discussed about what is visual VM profiler and why are we using this visual VM profiler and how to take a thread dump and Heap dump and it does not end up with that so today we're going to see how to explore the Hep dump and today we going to discuss about one of the most important part so this will definitely help you in finding most of the performance bottle legs whenever you face any issues in your application like there are chances that there might be high response times for a particular application so in those scenarios this particular part will definitely help you and in fact this video has start up with a question from one of our subscriber who asked why do we need or like what can we do or how can we find the performance Bott next in case if we do not have any monitoring tools so this has come out of that and this is again a open source tool in which you can install and it works in Windows and any any of the other operating systems and I have showed you how to take a heap dump so this Heap dump here which you see has been taken while we were running an Apache JM application so this is the one which I have executed to emulate the realtime for example this might something like this is or will be executing in your abs server Mission and you might need to understand like what's happening or like what are the things that is bringing down the application so let's see in this video on how to explore or what are the chances and how to identify the performance bot X without monitoring tool but with a visual VM profiler so with no further delay let's go to the video and before that this is me Shan I welcome you all to little YouTube Channel please don't forget to subscribe to our Channel if you have not subscribed yet like share and comment your questions and feedbacks in the comment section so here we have the Heap Dum let me just open it again for you in case if you have forgot it so here this is the snapshot which I have taken while the Apache Jer was running in this machion and when I took a snapshot had a heap dump so this is the Heap dump and last week we saw about these details like the Heap the summary of it and then the environment and then the classes by number of instances so today we will see the classes by size of instance because this is the main criteria where we can identify like what's happening in the background so we can go through it either by clicking on this or else we have another option where we can click C on the summary and then we can go through this objects so this way we can choose or we can navigate to the classes so these are the objects which were part of the applications for example if you are running an application Java application you might experience or you might observe all of these and here you can see you can see we have got lots of variables or lots of objects that are used in the application so similar to this you might have or you might observe things for your application you can see we have got int we have got B we have got java. lang. string so these are some of the objects that are part of the application and here you can see then the count of these objects that were used during the monitoring or while we are taking a heap down and then here here you can see the size of the objects so here you can see the count is 4197 which is just 1% of the total Heap but it occupies nearly [Music] 36.9% so this is actually a clue for us to tell us that that is something that has to be found or that has to be identified so how can we do that so before that let's see some some other objects as well here we have got the bite which is like 21.5% but it's still it occupies us a size of 28.1% which is like almost same which is almost similar because 21 per and 28% but still this part the in part is like 1% but it has occupied a size of 36.9 and then we have java. lang. string which is like 19.8% but the size of it is just 5.6% so same way we have we can like go through all of these items and we can in fact can sort these things out and then we can see but it's always better to sort on the size so that we can see what is the object that has taken the maximum amount of space or maximum amount of Heap okay before that let's see what are the options we have so we have got all objects which you can see or if we click on the dominators we can see what are the dominators in in fact if we have so here you can see so these are the dominators let me just click it again so the retained dominators are in this particular order so we've got 15.4% of java. .zip doz file. dollar Source I will take you this through this like what is happening and like why are we seeing this particular object here here and then the next part is the GC Roots so if you click on GC Roots we can directly navigate to The GC Roots here and it will take us through the java. l. class so we will see them one by one and then we have got so here these are the symbols the types we have got sticky class and we have got jna Global so all these objects are divided into these five types of objects and then these are the packages which are part of the application so in fact not only the objects but even the packages also might take a lot of space like might take a lot of Heap side heaps in your application then thirdly we have the classes so these are the classes these are the order of classes in which they were used and then we have got the instances so these are the individual instan es which we can find after the end of the test so this way we can go through each and every type of objects and we can navigate through them and we have got the preview window so if you select any of the for example the instances if I click on any of these instances here we can see the preview of it so we can see the fields if you click on the references it will take us to the references and if you want to see the GC root that's the critical part so we can see the GC root of it so first thing we will go to the first part or which is the main part which is all objects and under all objects let's go back to the top which is the in so here let we have have come back again to the int so these are the int objects which are part of the application so when we click on it let me just close these variables here so if I click on one of the int object this will show me the array items which is a kind of a preview and then here it shows what are the objects that they are referring to so here we can see this particular int object is being referred to all these Val Val so if you click on this references it will take us to the final part but here you can see under the GC route the garbage collection route and here we can see the let me just copy it for you just copying it now so this is what we have got and I have copied from here so the GC route the final part the garbage collection so let's see what exactly is that so in the context of the Java virtual machine memory management on garbage collection so the entry app context. ing. Apache J.G Mainframe as1 indicates the presence of a global reference to an object instance of the org. aache G.G main frame class within the Apache gometer application version 5.5 so I'm using the version 5.5 so here this exactly is what will tell you what exact application or which version of it so this is a kind of a doing a postmortem of your code and find what exactly is happening so this has clearly clearly tells you which version of application I'm using right so this is how actually it helps you in understanding your application as well okay let's now move on to this part so what is an app context so this app context refers to a member variable or field within an instance of the org. apach JG main frame class so it likely represents a reference to some application context object or data structure which are associated with the GUI main frame of of the Apache Jeter application so as I told you so app context is something which is related to the Mainframe application which is part of the Apache gometer 5.5 and then this part the org. Apache j.g. Mainframe so this is fully this is a fully qualified class name of the main frame class within the Apache Jeter application so in Jeter the main frame class typically represents the primary GUI because I've run this particular application through the GUI so that's what it's referring to so the main frame refers to the GUI or the frame where the user interacts with the application right and then the number one or the hash one so this denotes the specific instance of the main frame which is the the GUI part so in Java memory profiling which which we do now objects are often identified by unique identifi such as memory addresses or sequence numbers so in this case the hash one indicates that this is the first instance of the Mainframe class created during the applications execution for example in this example in scenario I've nearly used around like 10 users with 10 iterations so that might be like 100 100 iterations and this iteration is taken from the very first user or very first execution and that's what it's explaining so every every single detail can be taken out of this application using this visual VM profile and then this GC root jni Global so this indicates that the app context reference here the app sorry the app context reference held by the Mainframe instance is considered a garbage collection route specifically it's a global reference and GC roots or objects are references that are reachable by the jvm's garbage collector and prevent the referenced objects from being garbage collected so that's why we use this part and jna Global references are references held by native code which is written in C C++ that prevent Associated Java objects from be garbage collected and then finally the Apache j55 which I already told you which is the application which is the version of Pat gometer which I have used to run this test where I have taken a heap T so this is is just one example of the int so the next time the next video we will see about the java. Lang package so we'll see how does it work or what can be seen so here you can see it has come up with a different static files dot sorry class. java. .zip so we'll see that in our next video like what exactly is that how does it work so I believe this video would be very useful to you so until I meet you in another interesting video it's bye-bye from sham and LA