JDK-8139551 : Scalability problem with redefinition - multiple code cache walks
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-10-13
  • Updated: 2019-02-12
  • Resolved: 2019-02-05
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.
JDK 13
13 b07Fixed
Related Reports
Relates :  
JDK-8078725 - method adjustments can be done just once for all classes involved into redefinition
Relates :  
JDK-8139036 - Performance problem when retransforming classes at JVMD startup
Relates :  
JDK-8218601 - [AOT] Crash in AOTCodeHeap::mark_evol_dependent_methods
Description
Class redefinition walks the code cache for every class redefined (twice).  It could simply do one walk at the end of the entire redefinition.

The performance cost of walking code caches have been seen in using redefinition.
Comments
The performance improvements look impressive! It is from 1.5 to 3 times faster.
02-02-2019
To replace, walking the code cache for each class redefined, deoptimizing, and then walking the code cache to mark the deoptimized nmethods as not_entrant, this change splits up marking nmethods for deoptimization into two phases. The first phase is called per-class in the redefinition. The first phase marks any nmethods in the redefined class for deoptimization, by walking the InstanceKlass::_methods array. It also marks all dependent aot compiled methods of the redefined class for deoptimization. The second phase walks the code cache after all the redefined Method*s are marked is_old(). For each nmethod, the evol_method dependencies are walked, and if they depend on a Method is_old(), that nmethod is deoptimized. This change's performance was tested with a new JMH test. The first number is number of classes in the redefinition. old: RedefineClassesWithAgent.benchmark 10 avgt 10 30.403 �� 1.400 ms/op RedefineClassesWithAgent.benchmark 50 avgt 10 139.602 �� 21.684 ms/op RedefineClassesWithAgent.benchmark 75 avgt 10 264.462 �� 13.299 ms/op RedefineClassesWithAgent.benchmark 100 avgt 10 386.166 �� 15.206 ms/op RedefineClassesWithAgent.benchmark 150 avgt 10 832.416 �� 62.542 ms/op RedefineClassesWithAgent.benchmark 200 avgt 10 1366.589 �� 134.322 ms/op new: RedefineClassesWithAgent.benchmark 10 avgt 10 12.169 �� 0.812 ms/op RedefineClassesWithAgent.benchmark 50 avgt 10 48.767 �� 0.887 ms/op RedefineClassesWithAgent.benchmark 75 avgt 10 97.895 �� 1.618 ms/op RedefineClassesWithAgent.benchmark 100 avgt 10 196.316 �� 9.291 ms/op RedefineClassesWithAgent.benchmark 150 avgt 10 528.835 �� 31.934 ms/op RedefineClassesWithAgent.benchmark 200 avgt 10 915.002 �� 56.197 ms/op Note that all of the classes are walked by ClassLoaderDataGraph::classes_do() for each class redefined.
01-02-2019
I have a patch for this tested, but Eric is trying to adapt my test to the JMH framework to see what the performance difference might be. I expected more improvement than I got with a simple time comparison.
11-01-2019
[~coleenp] If I understand correctly you have a plan to work on it in 13. So, I'm targeting it there. Please, re-target it if necessary.
10-01-2019
Reopening. I would like to figure out how to make deoptimized nmethods that depend on the redefinition go straight to zombie so that MetadataOnStackMark doesn't have to walk the code cache looking for old methods as part of this work.
11-12-2018
We haven't actually had a customer complaint about this. Closing as WNF.
27-10-2017
Thanks, Coleen! I agree on targeting to 11.
14-04-2017
They are similar. The other one is walking metadata and this one is walking the code cache. The fixes are similar, I think. I linked them. Looks like we should attack these in 11.
14-04-2017
Coleen, This bug looks like a dup of the: https://bugs.openjdk.java.net/browse/JDK-8078725 But maybe it is supposed to cover something different. Could you, clarify, please?
14-04-2017