JVM/TI code review request (XS and M) (7182152) (original) (raw)
Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Feb 4 13:08:06 PST 2013
- Previous message: JVM/TI code review request (XS and M) (7182152)
- Next message: JVM/TI code review request (XS and M) (7182152)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Greetings,
I've updated the fix due to comments in Code Review Round 0.
Here is a summary of changes made to the various files:
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24) src/share/vm/oops/cpCache.cpp (HSX-25) src/share/vm/oops/klassVtable.cpp
- removed the new RC_TRACE_NO_CR() macro calls at Coleen's request; these files are outside of JVM/TI RedefineClasses proper so the tracing/debug style should not be dictated by JVM/TI RedefineClasses style that is currently in use
- did not touch the existing RC_TRACE... macros in the file; removing the existing macro calls would be outside the scope of this bug
src/share/vm/oops/cpCacheOop.cpp (HSX-23.6, HSX-24) src/share/vm/oops/cpCache.cpp (HSX-25)
- copy a comment from ConstantPoolCacheEntry::is_interesting_method_entry() to ConstantPoolCacheEntry::check_no_old_or_obsolete_entries()
src/share/vm/oops/klassVtable.cpp
- Copied the new comment intended to prevent the "break" from re-materializing again from klassItable::adjust_method_entries() to klassVtable::adjust_method_entries(); yes, I'm paranoid.
In the HSX-25 version only: src/share/vm/oops/metadata.hpp
- revert changes
src/share/vm/oops/cpCacheOop.cpp src/share/vm/oops/klassVtable.cpp
- wrap uses of is_valid() in NOT_PRODUCT macro as appropriate
Here are the URLs for the updated webrevs:
http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx23.6/ http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx24/ http://cr.openjdk.java.net/~dcubed/7182152-webrev/1-hsx25/
The JPDA stack testing that I started on Friday is still running on WinXP so I'm blocked for checking the recompile due to these changes. I'll start a recompile on Solaris X86, but that will take some time.
Thanks, in advance, for more comments, suggestions or questions.
Dan
On 2/1/13 12:55 PM, Daniel D. Daugherty wrote:
Greetings,
I have a fix for the following JVM/TI bug: 7182152 Instrumentation hot swap test incorrect monitor count http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7182152 https://jbs.oracle.com/bugs/browse/JDK-7182152 The fix for the bug in the product code is one line: src/share/vm/oops/klassVtable.cpp: @@ -992,18 +1020,50 @@ // RCTRACE macro has an embedded ResourceMark RCTRACE(0x00200000, ("itable method update: %s(%s)", newmethod->name()->asCstring(), newmethod->signature()->asCstring())); } - break; + // cannot 'break' here; see for-loop comment above. } ime++; } } } and is applicable to JDK7u10/HSX-23.6 and JDK7u14/HSX-24. Coleen already fixed the bug as part of the Perm Gen Removal (PGR) project in HSX-25. Yes, we found a 1-line bug fix buried in the monster PGR changeset. Many thanks to Coleen for her help in this bug hunt! The rest of the code in the webrevs are: - additional JVM/TI tracing code backported from Coleen's PGR changeset - additional JVM/TI tracing code added by me and forward ported to HSX-25 - a new -XX:TraceRedefineClasses=16384 flag value for finding these elusive old or obsolete methods - exposure of some printing code to the PRODUCT build so that the new tracing is available in a PRODUCT build You might be wondering why the new tracing code is exposed in a PRODUCT build. Well, it appears that more and more PRODUCT bits deployments are using JVM/TI RedefineClasses() and/or RetransformClasses() at run-time to instrument their systems. This bug (7182152) was only intermittently reproducible in the WLS environment in which it occurred so I made the tracing available in a PRODUCT build to assist in the hunt. Raj from the WLS team has also verified that the HSX-23.6 version of fix resolves the issue in his environment. Thanks Raj! Here are the URLs for the three webrevs: http://cr.openjdk.java.net/~dcubed/7182152-webrev/0-hsx23.6/ http://cr.openjdk.java.net/~dcubed/7182152-webrev/0-hsx24/ http://cr.openjdk.java.net/~dcubed/7182152-webrev/0-hsx25/ I have run the following test suites from the JPDA stack on the JDK7u10/HSX-23.6 version of the fix with -XX:TraceRedefineClasses=16384 specified: sdk-jdi sdk-jdiclosed sdk-jli vm-heapdump vm-hprof vm-jdb vm-jdi vm-jdwp vm-jvmti vm-sajdi The tested configs are: {Solaris-X86, WinXP} X {Client VM, Server VM} X {-Xmixed, -Xcomp} X {product, fastdebug} With the 1-liner fix in place, the new tracing code does not find any instances of this failure mode in any of the above test suites. Without the the 1-liner fix in place, the new tracing code finds one instance of this failure mode in the above test suites: test/java/lang/instrument/IsModifiableClassAgent.java There are two new tests that will be pushed to the JDK repos using a different bug ID (not yet filed): test/com/sun/jdi/RedefineAbstractClass.sh test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh There will be a separate review request for the new tests. I'm currently running the JPDA stack of tests on the JDK7u14/HSX-24 and JDK8-B75/HSX-25 versions of the fix. That testing will likely take all weekend to complete. Thanks, in advance, for any comments and/or suggestions. Dan
- Previous message: JVM/TI code review request (XS and M) (7182152)
- Next message: JVM/TI code review request (XS and M) (7182152)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]