JDK-4910812 : Enhance Hot Code Replacement
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 1.4.0,1.4.2,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,solaris_7,windows_xp
  • CPU: x86,sparc
  • Submitted: 2003-08-21
  • Updated: 2014-06-06
  • Resolved: 2012-12-01
Related Reports
Duplicate :  
Relates :  
Description
Name: rmT116609			Date: 08/21/2003


A DESCRIPTION OF THE REQUEST :
As of JDK1.4.x it is possible to replace running "hot" code, as long as this does'nt affect the class' public signature in general.

  To really ease and speed development, this "hot code replacement" feature should be extended to include the possibility to alter class level and other "signature changing" operations (alter/add/remove methods and instance variables).

This would of course break serialization going out of the runing VM, but within the VM should be able to cope with the changning signature.

I believe, as far as I can remember, that the old IBM Visual Age for Java tool had a similar capability, where it was possible to alter almost everything without a "reboot" of the VM.


JUSTIFICATION :
Ease Of Development!

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Hot Code Replacement extended to include class-signature changes within the single running VM.
(Incident Review ID: 192049) 
======================================================================

Comments
This RFE is obsolte. It is to enhance Class Redefinitions with binary compatible changes. Another CR will be crated based on the JEP which is currently considered for JDK 8: http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-July/004321.html We will also have to open new corresponding RFE's for JDI, JDWP and JPLIS (core-svc/debugger and core-svc/java.lang.instrument)
01-12-2012

EVALUATION Extending RedefineClasses and RetransformClasses to allow the addition of methods and to allow some method attribute changes is currently planned for Dolphin. However, Dolphin feature work has not been finalized. Also, because of the complexity of this work, it may only be supported for use during development.
21-03-2006

EVALUATION A number of years ago we invested in research in this area. The paper "Towards Flexible and Safe Technology for Runtime Evolution of Java Language Applications" by Mikhail Dmitriev provides an overview of this research: http://www.experimentalstuff.com/Technologies/HotSwapTool/runtime-evol.pdf At this time we have no plans to support arbitrary changes to classes at runtime. We are however conscious that a number of developers are seeking the current restrictions to be relaxed in the development environment. That is, for "fix & continue" debugging developers are looking for ways to update classes in the IDE/debugger without needing to restart the application. In addition there are tools that do instrumentation looking to do limited changes. We are not adverse to making improvements but it is a topic that requires further research. To that end it would be useful if developers voting for this RFE could detail their specific requirements. Are people really looking to do arbitrary changes and instance conversion? We view type safety and application consistency as very important. One approach is to relax the restrictions and allow for some limited changes - for example, the ability to add methods would address many scenarios. We aren't making any commitments at this time but we are looking for feedback. This forum thread would be an appropriate place to add feedback: http://forums.java.sun.com/thread.jspa?threadID=572396&tstart=0 We are interested in detailed information about specific features.
25-10-2005