JDK-6173565 : RedefineClasses must be fast even when hundreds or thousands of classes are redefined
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 1.5.1,6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2004-10-04
  • Updated: 2012-10-02
  • Resolved: 2012-10-02
Related Reports
Relates :  
Relates :  
Relates :  
Description
JFluid typically instruments a program by redefining every loaded class.  In J2SE 5.0 redefining 2000 classes which have been extensively run (and thus have many compiled methods) takes 191 seconds, which is around twenty times slower than the experimental JFluid VM.

This is caused in large part by CR 6173560.  However, there are other serious inefficiencies which must be addressed.
###@###.### 10/4/04 00:22 GMT

Comments
EVALUATION Adding a new cache mechanism is too risky for Mustang at this stage. All of the simple optimization have been done with 6173560 so I'm committing this bug to Dolphin.
08-03-2006

EVALUATION The constant pool merging work was done with 5088035. This bug remains open to address performance improvements that require larger amounts of code (e.g., new cache mechanism or interesting references lists). 6173560 will used for simple performance fixes (e.g., loop optimizations, code restructuring) and any stress related fixes found by the RedefineClasses stress kit.
27-01-2006

EVALUATION -- One of the profiler vendors has provided 3 test cases to demonstrate the performance issues that they are observing. I have attached these to the bug (see comments section). Also I have examined the timing and I see that 90% of the time is spent in VM_RedefineClasses::adjust_cpool_cache_and_vtable adjusting the references from other classes to the redefined class.
27-09-2005

SUGGESTED FIX Fixed include use of hashtables instead of sequential search. ###@###.### 10/4/04 00:22 GMT
04-10-2004

EVALUATION Must be fixed ###@###.### 10/4/04 00:22 GMT
04-10-2004