Why is Java's debugging Hot Swap limited to intra-method changes?

I have gone through hot deployment tutorial and it works. But i have questions about the limitations(point 3) i.e

Hot deploy has supported the code changes in the method implementation only. If you add a new class or a new method, restart is still required.

Basically why we don't need server restart if i make changes in existing method but required in case of adding method or class.

My understanding how it works :- When i make the changes in existing method or introduced a new method, Eclipse will place the file the at right location under webserver. If class has been already loaded by classloader in perm gen space, it will unload it from permgen space and load the new the one internally without server restart so that new changes(byte code) is reflected . Is that correct ?

If yes why hot deployment does not work for new methods and new class files ?

Solution 1:

The reasoning is quite complicated and really only fully known to people with intimate knowledge of the JVM and how it manages memory. There is a decent explanation here: Java HotSwap Guide (although it's really an advertisement for the JRebel product) - scroll to the section titled Why is HotSwap limited to method bodies?.

The gist: there are two primary factors that prevent HotSwap from handling structural changes to classes: JIT and memory allocation.

The JIT (Just In Time) compiler in the JVM optimizes the bytecode after classes have been loaded and run a few times, basically inlining many calls for increased performance. Implementing that feature safely and effectively in an environment where class signatures and structure can change would be a significant challenge.

Other problems surround what would happen regarding memory management if class structures were allowed to change. The JVM would have to modify existing instances of classes, which would mean relocating them to other parts of the heap storage. Not to mention having to relocate the class objects themselves. The JVM's memory management is already incredibly complex and highly optimized; such changes would only increase the complexity and potentially reduce performance of the JIT compiler (and likely lead to additional bugs).

I think it's safe to assume that the JVM engineers have not been willing to take the performance and bug footprint tradeoffs that would be required to support this feature. Which is why products like JRebel and others have come to exist.

Solution 2:

As a side note, the specification itself is not limited.

It just happens some of the available implementations, including the ubiquitous Reference Implementation, are limited.

After you connect to a remote VM, you can check whether it allows to add methods or redefine classes.

Solution 3:

You can if you run your java on a smalltalk vm. Smalltalk has been doing this basically forever, and it is one of the reasons why Smalltalkers tend to do debugger driven development as a superior form of test driven development. Smalltalk vms do the required clean-up of memory data structures. In Eliot Miranda's Spur (for Squeak, Pharo and Cuis) and Gemstone that is done lazily, but otherwise you might have to wait for all objects to be migrated. The reference implementation java vm probably has more optimizations than any smalltalk vm you could run java on a.t.m.