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

Question

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 ?

Margetts

It's not eclipse hot deployment; it's JPDA. – Scleroma

ok. But still the question is same i.e how it works internally whether its eclipse or some other tool. I just mentioned eclipse as I am using it – Margetts

That's why I gave you the link to JPDA. – Scleroma

@ElliottFrisch I did not find anything related to my question in the link, Is there any specific section there I can look into ? – Margetts

This project may be related. github.com/dcevm/dcevm It modifies the jvm to allow more change. Take a look at its source code, may be you get something. – Lucretialucretius

I suspect jrebel faq will be interesting read for any who visits this question : zeroturnaround.com/software/jrebel/learn/faq – Nifty

Answer 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: Java HotSwap Guide section titled Why is HotSwap limited to method bodies? (although it's really an advertisement for the JRebel product).

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.

Mammon

To understand it can you please provide you thoughts on #35249734. Thanks in advance – Margetts

regarding your statement The JVM would have to modify existing instances of classes, which would mean relocating them to other parts of the heap storage. This is true when developer is changing within method also. In that case old class definition need to be taken of and new one needs to be loaded in permgen space is n't it ? – Margetts

@emilly, I don't think the compiled method implementations are stored with each instance, but data definitely is. – Mammon

Agreed class definition is not stored with each instance but stored once in perm gen area. My question is even when developer is changing within method also , old class definition need to be removed and new one needs to be loaded in permgen space is n't it ? If that's the case relocation should be valid in both cases either developer introducing new method or modification with in the method. Right ? – Margetts

how could hotswap be implemented if the method inline is considered? – Eddra

Answer 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.

Hodeida

Good to know, though, sadly, not practical if you can't use a JVM that supports those advanced features. I think that's new in Java 8, by the way. – Mammon

@E-Riz, no, those methods all exist since 1.4. – Alpaca

Answer 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.

Marciamarciano

Answer 4

The answer provided by E-Riz already has a good explanation of the reasons why the standard Java HotSwap technology only supports the modifications to existing methods and not addition of new class or methods to classes.

However, as has been described in a related SO discussion the level of hot swapping you achieve is dependent on the tool chain you use. So, if you end up adding JRebel plug-in you would be able to perform hot swapping even when new methods and classes have been added.

There is another project :Hot Swap Agent - this is typically a java agent that can be used to run your Java container and you can activate it using a couple of command line parameters (as mentioned in the quickstart).

Ultimately