What do you mean "feasible"? They all work more or less the same way, and have the same basic feature set. I think the major ones--JProfiler, JProbe, and OptimizeIt--all offer demo or limited versions for free, so you can try a few, compare features and price, and pick what's best for you.
I am using yourkit profiler. It shows how much memory occupied in the heap and shows howmany classes loaded , how many are garbage collected... But i didnt get clear picture how to move the unused objects to garbage collection by using the profiler identification?
chaitanya krish wrote:I am using yourkit profiler. It shows how much memory occupied in the heap and shows howmany classes loaded , how many are garbage collected... But i didnt get clear picture how to move the unused objects to garbage collection by using the profiler identification?
You don't use the profiler to release memory. You use it to identify where your program may be using too much memory, and then, if needed and feasible, you go back and change your code so it doesn't use so much.
And we don't need to "move unused objects to garbage collection". That's done automatically. However, if you want your profiler to force a GC, just so you can get a better look at the memory that's actually used, then there should be a "Perform GC" button, or something similar. The specifics can be found in the docs or help feature of the particular profiler you're using.
Before you profile, you have to be sure of what you're profiling for. Is your application generally slow? Are only some actions that are slow? or do you want to find out, in general, how your application is performing and how can you make it perform better?
Typically, for memory leaks, you will use the profile the application over a period of time and use the application as you normally would. If there is a memory leak, sooner or later, your heap is bound to have more objects (the increase in usage can be sudden, if the code is real bad, or gradual). You would then search your code to find out where those objects are coming from and why are they staying in the heap over a period of time. Then you try to fix the code if possible or tweak the parameters (may be increase the heap, connection pooling and other stuff depending on what is causing the leak) and then profile again.
Googling doesn't make you a genius. But not Googling makes you dumber.
Catch Ernie! Catch the egg! And catch this tiny ad too: