Geert Bevin: How badly do you want Hotswap to improve?

Discussions

News: Geert Bevin: How badly do you want Hotswap to improve?

  1. Geert Bevin, in "How badly do you want Hotswap to improve?," asks if developers would like the ability to use Hotswap with classes that change basic class structure, pointing to a discussion on Sun's developer network. This might be crucial for scripting support in Java.

    Hotswap is described as "the ability to substitute modified code in a running application through the debugger APIs. For example, one can recompile a single class and replace the old instance with the new instance." The use of the debugger API for this seems odd, but the documentation specifies that it's also for use during production, saying that "Organizations deploying long running servers wish to be able to fix bugs without taking down the server."

    However, as Geert points out, you can replace the bytecode but you can't change the structure of your class, to add new methods, for example.
    Developers are more and more seeing the advantage of scripting languages for development and part of the reason is the fact that any change can immediately be seen in a running application.
    Other applications might include hot deployment of an enterprise application, as well.

    Sun's discussion forums have a discussion dedicated to this, so if you're interested, read Hotswap support for schema / shape changes.

    Threaded Messages (29)

  2. As I also stated on the discussion you refer to, for sake of implementation speed the focus should be on development. If we start about production it will take longer or will never take place. I dove into this as deep as I can with respect to my background and knowledge. For what I understand it is doable within one VM.

    I want this so badly that I am actually browsing the mustang source to see what i can do myself. Building the darn thing only is already a tremendous task. Let alone finding out where and how to allocate memory for the extensions. Conceptually it is pretty easy what has to be done, but where o where in those 300.000+ lines of code. On one hand I feel ridiculous for even trying but on the other I am already learning an awfull lot about the VM before even seriously trying it.
  3. As I also stated on the discussion you refer to, for sake of implementation speed the focus should be on development. If we start about production it will take longer or will never take place.
    I agree, but let's not forget other gains we could have in production too, like the ability to evolve code dinamically with HA distributed apps and/or caches. One could "upgrade" classes in a live distributed app, and the VM should be able to have different versions of a class coexisting for a time in the same VM, until every object change from the old to the new class version as they are created and destroyed, for example. That could improve HA, I suppose. Though I couldn't say what would be the implications WRT remoting in such a situation.
  4. Dynamic redeployment[ Go to top ]

    let's not forget other gains we could have in production too, like the ability to evolve code dinamically with HA distributed apps and/or caches. One could "upgrade" classes in a live distributed app, and the VM should be able to have different versions of a class coexisting for a time in the same VM, until every object change from the old to the new class version as they are created and destroyed, for example.

    Redeployment of an application in an appserver pretty much covers this requirement already, including allowing addition and removal of methods to classes. Of course, appservers do this by providing standard interfaces / contracts that your redeployable components must implement, and these interfaces cannot mutate.

    However, in the J2EE component environment, the thing that is redeployed is the component, not a particular class. Class-granularity redeployment / redefinition doesn't give us anything new from an availability standpoint. And arguably, the component is the right level of granularity for hot redeployment anyways. The big benefit of finer-grained redefinition is that we'd be able to implement new language capabilities that let the application change itself over time.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  5. Dynamic redeployment[ Go to top ]

    The big benefit of finer-grained redefinition is that we'd be able to implement new language capabilities that let the application change itself over time.

    Oops, I meant to say "From a production standpoint, the big benefit of finer-grained ...". Obviously, from a development standpoint, it'd be sweet to have VM-level hooks to reduce the time taken to see new changes.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  6. [..] let's not forget other gains we could have in production too, like the ability to evolve code dinamically with HA distributed apps and/or caches. One could "upgrade" classes in a live distributed app, and the VM should be able to have different versions of a class coexisting for a time in the same VM, until every object change from the old to the new class version as they are created and destroyed, for example. [..]

    The transition from one version to another can already be accomplished pretty seamlessly. It's common for our customers to deploy a new version of the application one VM at a time, taking down each VM (running the old version) and restarting it (running the new version). This allows full application upgrades with no discontinuity of application availability. In fact, it's kind of like hot-swapping CPUs in an HA server.

    The primary problems are (not surprisingly) related to the form of the data that the different versions of the application produce and consume, since those forms can change from version to version. Java serialization has some helpers for this (serial version UID) and we've shown some patterns for dealing with it on optimized binary serialization. See:

    http://www.tangosol.net/forums/thread.jspa?threadID=628&tstart=0
    Though I couldn't say what would be the implications WRT remoting in such a situation.

    Remoting, in terms of RMI and its convoluted cousins, is a very fragile concept, and (IMHO) encourages the worst type of distributed application architectures (the "CORBA-like spaghetti hell"). If you are going to decouple, then decouple (JMS + MDB, SOA, whatever). If you aren't going to decouple, then it is almost inconceivable why you would want to remote. Again IMHO $.02 FWIW IANAL etc. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
  7. I was thinking about evolving classes _without_ taking nodes down, but since the end result is the same with what is possible in distributed apps today (incremental upgrade by reloading nodes one at a time), the benefit is not so great indeed.

    Thanks for the explanations.
  8. +10[ Go to top ]

    All people around me will be also excited about possiblity to replace class at development time. We should start JVM with special option which will allow us to replace any class.
    Of course because of consistency it should be dissabled at normal runtime.
  9. +1[ Go to top ]

    Not only would full Hot swap be useful for AOP, but it would also be very useful to enable RoR like development where coding->runtime is lightning fast. Classloader tricks only take you so far.

    Also, I'd like to see some of the AOP stuff JRockit has in its VM added.
  10. +1[ Go to top ]

    Couldn't agree more. I think the biggest single advantage cited by the RoR crowd that the community can't solve on it's own is the instant edit/refresh ability. Given average startup times for app servers these days, a less restrictive hot-swap implementation would be like manna from heaven. (Ok, maybe I exagerate, but I'd be pretty excited).

    -Tim Fennell
    Stripes: Because web development should just be easier.
  11. +1[ Go to top ]

    Not only would full Hot swap be useful for AOP, but it would also be very useful to enable RoR like development where coding->runtime is lightning fast. Classloader tricks only take you so far.Also, I'd like to see some of the AOP stuff JRockit has in its VM added.

    To be clear, this would be a development time-only tool, not for production use. This hasn't been implemented yet because it's not appropriate for production (it wouldn't be predictable/reliable enough), but it would be awesome for development.
  12. Java Instrumentation package[ Go to top ]

    Hasn't the coupling between class redefinition and debugging been eliminated with the introduction of the java.lang.instrument package? Of course, class redefinition still must obey lots of restrictions. From the javadoc:
    The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions.

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  13. Java Instrumentation package[ Go to top ]

    Hasn't the coupling between class redefinition and debugging been eliminated with the introduction of the java.lang.instrument package? Of course, class redefinition still must obey lots of restrictions. From the javadoc:
    The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions.
    -Patrick-- Patrick Linskeyhttp://solarmetric.com

    Patrick, those restrictions make it pretty much useless in practice, hence the request for improvement.
  14. Java Instrumentation package[ Go to top ]

    Patrick, those restrictions make it pretty much useless in practice, hence the request for improvement.

    Yup, I was just addressing the point in the original post that said "The use of the debugger API for this seems odd, but the documentation specifies that it's also for use during production".

    -Patrick

    --
    Patrick Linskey
    http://solarmetric.com
  15. BTW dont' forget to vote
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4910812

    And give 'm all your 4 votes you have.
  16. +1. Critical for productivity.
  17. Critical to productivity +1[ Go to top ]

    I have used myeclipseide and the is a problem when I'm creating webb application. Whenever I changed the class a bit more the Tocat(or another) server fails!!!

    Restarting takes from 3-10 minutes, because some cache errors were there and I need to clean them.

    MORE MATURE(RELAXED) HOTSWAP will be VERY HELPFULL.
  18. The IBM VM's (J9) have been supporting method adds/removes since 1.4.2 (about 2 years).
    Now, instance shape changes or class hierarchy changes are a completely different animal :-(
  19. The IBM VM's (J9) have been supporting method adds/removes since 1.4.2 (about 2 years). Now, instance shape changes or class hierarchy changes are a completely different animal :-(

    j9 in debugmode sometimes does not call the subclass but the baseclass method. But not if you break and step, with system. out I found out eventually. I think sun can do a better job than that.
  20. If you've got a test case that doesn't work according to spec, I'm sure the J9 people would be interested to know.
    <flame on>
    As for Sun doing a better job: they came up with that braindead hotswap spec that doesn't even let you drop main(), when all they would have had to do was copy what J9 was doing long before. So no, I don't think they can!
    <flame off>
  21. If you've got a test case that doesn't work according to spec, I'm sure the J9 people would be interested to know. <flame on>As for Sun doing a better job: they came up with that braindead hotswap spec that doesn't even let you drop main(), when all they would have had to do was copy what J9 was doing long before. So no, I don't think they can!<flame off>

    Today is my first at a new job. No ibm there so I won't be able to reproduce that.

    Ok then let me hope that SUN does a better job.
  22. It seems that certain people confuse hotswap with hotdeploy.
  23. W[ Go to top ]

    I think this is absolutely crucial.
  24. At least conceptually, this would have to work like a transactional database of code files. Otherwise there's no way to make multiple changes to a running system without creating temporary inconsistencies.

    Instance conversion is probably easier to tackle by designing the application so that it keeps session data in generic data structures whose classes rarely change, and swap them in and out of objects as needed (I can already hear OO purists gnashing their teeth).
  25. +1[ Go to top ]

    IMO this is perhaps the biggest and most easily fixable remaining hindrance to productivity in Java. There is simply no good reason why we shouldn't be able to change the schema of classes when running in debug mode. Previously, Java productivity was limited by bad frameworks. Now with a new generation of frameworks and standards (such as EJB3) that emphasise productivity, this limitation is going to become the bottleneck.

    This is something that should most certainly be addressed in the scope of Java 6, and I hope the Java SE guys are looking at it.
  26. from forum.java.sun.com[ Go to top ]

    If it would be done then where would that be? I have
    > been browsing the mustang source.

    That is a great place to start.

    You will find the JVM TI implementation of the current Hotswap functionality in these files:

    hotspot/src/share/vm/prims/jvmtiRedefineClasses.cpp
    hotspot/src/share/vm/prims/jvmtiRedefineClasses.hpp



    For those who don't have the Mustang source yet, start by downloading the bundle(s) here:
    https://mustang.dev.java.net/
  27. Yet here and the sun bug there are nothing but supportive comments.
    Occasionally bytecode modification of methods is a nice short cut - you avoid having to restart to test the logic, fair enough, maybe it is even reasonable to add/remove private methods in the process - but each of these comes at a cost - the cost for changing code is low so the occasional usefulness justifies it. The cost of changing instance variables, extension, or exposed methods is much greater, for a very minor gain - I'm not against it, but don't expect me to be happy if it inteferes with something useful.
    Any change of this kind must affect more than one class - thus is reasonably approached by redeploying the whole system - for a client app this should be quick, and for a server app if you have a half way decent app server you can hot deploy in no more than 30 seconds, probably a great deal less time than any other part of the process.
    <rant>
    Like most Java programmers I have spend hours in the "change, compile, test" debug loop. Apparently, unlike most of my peers I have realsed that it only happens when I am being really, really dense (and the code I get at the end of the process shows it).

    The correct loop is "identify problem, design solution, change code, compile, test" - if you go around more than a few times then you have either failed to do the first two, or entirely failed to understand the logic of you own program. Anything else is evolutionary programming - mutation and selection without design - this is how you end up with dependencies on undocumented "features", suprise lack of function due to missing test cases, and code that looks like it was written by an monkey on crack.
    This is exactly what is wrong with most PHP programs - code is written not as a solution of the problem, but because it "seems to work".
    (XP does not justify not thinking!)
    </rant>

    That said something, in this style is required to support scripting languages efficiently - but that is a quite distinct issue - it may be VM but its not Java.
    The immutability of class signatures (hence Class objects) is a core assumption is Java - changing it would introduce more bugs that it would ever fix.
  28. The correct loop is "identify problem, design solution, change code, compile, test" - if you go around more than a few times then you have either failed to do the first two, or entirely failed to understand the logic of you own program. Anything else is evolutionary programming - mutation and selection without design

    How about the correct loop AND being able to continue. I understand that you like us to be protected from ourselves. There is still normal running mode where nothing should change. In the "correct loop" you don't need a debugger anyway.
    This is exactly what is wrong with most PHP programs - code is written not as a solution of the problem, but because it "seems to work".

    You cannot compare apples with other fruit. I understand your concern but I think you don't have to worry that much, we will not code crappier than we already do.
  29. At the times of Visual Age 4 Java (and it's integrated UVM) you could start your Appserver in the morning and keep working on code the whole day without restarting the appserver.
     Nowadays even with 1.5 JDK you must restart the whole appserver event o fix minor bugs, add constants etc...
  30. Yes, please yes. Don't make me go over to the Ruby camp! ;)