Serguei,
This looks nice. I thought this change was going to delay calling
AdjustCpoolCacheAndVtable until the end of the redefinition, rather than
for each class, so was a bit confused by the change.
Your change is a nice cleanup and improves MethodHandle method
replacement performance.
Your backport may not be simple for jdk8 because PreviousVersionNode is
another type and not an InstanceKlass. Maybe you've convinced me that
it's worth backporting those changes too. Let me know.
Thanks,
Coleen
On 4/10/15, 4:29 PM, [email protected] wrote:
Hi Coleen and Dan,
This is the second class redefinition scalability/optimization fix
that is in my queue to push into 9 and 8u60.
The approach is similar to the first one but much smaller.
For convenience, these are the links to the first scalability fix:
Bug report: https://bugs.openjdk.java.net/browse/JDK-8073705
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/
Please, let me know if you have any chance to review this.
This is the last one that is waiting for your attention! :)
Thanks,
Serguei
On 3/26/15 7:38 PM, [email protected] wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8073705
Open hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
Summary:
This is the 2-nd round of performance/calability fixes in class
redefinition.
This time, the two remaining issues that were left alone in the
first round fix:
- optimized ConstantPoolCache::adjust_method_entries() is used
for previous versions
- the MemberNameTable::adjust_method_entries() has been
optimized too
- some cleanup
Testing:
In progress: nsk redefine classes tests, JTREG
java/lang/instrument, com/sun/jdi
Thanks,
Serguei
