JDK-8139036 : Performance problem when retransforming classes at JVMD startup
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Incomplete
  • Submitted: 2015-10-07
  • Updated: 2020-06-26
  • Resolved: 2020-06-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
Relates :  
Description
When JVMD starts it retransforms loaded classes. 
We saw that retransformation takes a long time per class (in certain cases it took about 1 second per class).
The amount of retransformed classes varies according to the environment and to the time JVMD was deployed (if it is deployed right after jvm satrtup less classes will be retransformed then if it is restranformed later).
In the current implementation retransformation is done one class at a time, but the problem occurs also if all the classes are retransformed at the same time.
The retransformed classes do NOT have large amount of attributes or methods
Comments
I'm closing this enhancement as incomplete. We need a reproducible testcase or more precise description about what does not scale. Otherwise, this enhancements is too abstract and general. Please, reopen this after you add more details.
26-06-2020

There were a couple of performance issues fixed in this area shortly after this CR was filed: JDK-8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale JDK-8073705: more performance issues in class redefinition The following is still open: JDK-8078725: method adjustments can be done just once for all classes involved into redefinition And the following was closed as WNF due to no reports of it being an issue: JDK-8139551: Scalability problem with redefinition - multiple code cache walks
11-07-2018

Please provide a test case that reproduces the performance problem
11-07-2018