Instead of talking about missing features in Java, if you ask anybody using Java (or someone even not using Java), what is special about Java? The answer will definitely have two things- platform independent language and garbage collection. There will be a long list of other items but these two will be on top the list.
General assumption about cleaning one’s own garbage in Java is – don’t worry, Java has robust garbage collection mechanism. If you ask me, I would say – not worrying about own garbage is not a good habit. You create dirt, and leave it behind for someone else to clean it is definitely not acceptable. This means you are becoming lazy. But developers have acquired this habit and lived happily as long as the application does not hit with an annoying ‘OutOfMemory Error’. When this error is encountered, then all the trouble starts. This is the time when most of us go back, and read/explore/try to find out what Java does to clean up my garbage. There we understand that this error is thrown by the throughput collector when it spends 98% of time in cleaning up the garbage and it recovers just 2% of heap memory. Means it is messed up now. This is the time when we understand that there is some kind of blunder is created by us while writing or configuring the application. This is the time when we go and try to tune one of the following areas –
- Application memory usage
- JVM memory allocation
- JVM garbage collection (command line) parameters
- Machine processor
And what not. I also ended up doing this business. After few tricks and twists I got application working fine, but I could not resist consolidating these things which would have definitely helped me a lot in Java. I don’t know if there is anybody who is actually sitting and compiling such requirements and taking them forward in Sun (Ok Oracle’s) Java lab. Still here is the list.
Garbage Collection Free Memory Location:
As most of the developers have spent enough time in writing Java programs, they can now, at least now, predict the time when certain object will no more be referenced, and it can be garbage collected. This also means that, developers can identify those objects, which will never get garbage collected. Yes! I mean those objects which will be created at the application start up, and keep in memory until the application is actually shut down. It can be application start up servlet, or a non expiring huge master data cache. Such objects will keep hanging in memory until the application is shut down. But when JVM looks at these objects, it moves these objects in tenured generations and structure of these classes in permanent generations. But when major GC happens, JVM does scan through these live objects in tenured generations. Imagine this happening every time the major GC happens. Why is this scanning required when developer already knows that these objects are definitely going to be in memory till application’s ends its life? This is where we need a memory area where we push a object, or mark it so that JVM stores it in this memory area and never goes back and scans it identify garbage collection opportunity. By having such mechanism, what we achieve is reduction in the major GC time, because JVM will have lesser area to check for dead objects.
Configure JVM While Installing:
It may be that I believe in proactive action than reaction. But I find nothing wrong in it. Reactive correction means the damage is already done, and what we are trying to do is fix it. We might have paid the cost of damage already. Java application developers, architects and deployment teams know the kind of application they are deploying. If not then they should do the homework before pushing any application into production. They also know the kind of JVM set up that will be suitable for such type of application. It may be based on the data provided by Java or based on their personal experience. When the machine is set up with JVM, they need a feature to configure JVM at that very moment. Select few options and JVM is set up. This can be default configuration which can be overridden by the Application server riding on this JVM at runtime. But at least we have a default configuration which is expected to produce good application performance.
Why do I need an external profiler to know what JVM is doing? How many objects it is creating? How much time each method is taking to complete? There can be a sophisticated in-build profiler which collects all this data on configuration and presents elegantly. JVM is the best place to have this data, JVM only knows the details of created and garbage collected objects. Then there should be mechanism to view these details to analyze application for any purpose.
Good JVM Monitoring:
JVM knows – how it’s different internal processes are behaving. When minor and major GC are getting triggered? How much memory it is creating? Details about movement of objects from one generation to other. So much information is readily available with JVM. Just that, it is not accessible outside in good way. It would be a good insight to know how all these factors are behaving. Also a view of memory/object graph will help in tuning application and even JVM better.
I know all of us must be having similar list of themselves. I think it is time to share.