Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

RMI Unpluged Blog

Posted by kcpeppe-JavaNet Jan 27, 2015
I've just finished tuning a client's application where one of the items on the table was to find the source of calls to System.gc(). Using Censum made easy work of understanding the source of the calls. The team I was working with not only missed that these calls to System.gc() where creating havoc with their end users experience, they didn't even realize that something, some where was messing things up! It's not to say that developers are completely oblivious to the issue. Developers have gotten better about not placing calls to System.gc() in their code, but they often still don't see the call being made in their GC logs. One of the confusing causes of unwanted calls to System.gc() comes from Java (typically Java EE) applications that have remote objects, and therefore use RMI. In the early days these calls came into applications at the rate of 1 a minute and as you can imagine, it caused a lot of consternation for those analyzing the performance of Java EE applications making use of Session or Entity beans. After much discussion, the call rate was reduced to the current rate of once an hour. Better but it can still be disruptive as much as it can be useful. Lets expose a little bit of how the JVM works by digging into how RMI plays with the Garbage Collectors. The Remote Procedure Call (RPC) protocol (originally written in C) allowed one process to call an exposed function in another process. The function in the other process was expected to manage all of it