Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
Hi, The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks, Katja On 03/25/2014 01:14 PM, Staffan Larsen wrote: I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for the record: please don’t push this until jtreg with the fix has been promoted. Thanks, /Staffan On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: Hi, Could I please have a review of this fix. webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8034960 When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. Verified locally since no JTreg with fix has been promoted yet. Thanks, Katja
Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: > > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ > > src/share/vm/runtime/sharedRuntime.hpp >No comments. > > src/share/vm/runtime/sharedRuntime.cpp >line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >I'm not sure that JRT_LEAF is right. I would think that >JvmtiExport::post_method_exit() would have to grab one or >more locks with all the state checks it has to make... > >For reference, InterpreterRuntime::post_method_exit() >is a wrapper around JvmtiExport::post_method_exit() >and it is IRT_ENTRY instead of IRT_LEAF. Good catch! > > src/cpu/sparc/vm/sharedRuntime_sparc.cpp >No comments. > > src/cpu/x86/vm/sharedRuntime_x86_32.cpp >No comments. > > src/cpu/x86/vm/sharedRuntime_x86_64.cpp >No comments. > > I'm guessing that PPC has the same issue, but I'm presuming > that someone else (Vladimir?) will handle that… Yes, I was hoping that I could file a follow-up bug for the platforms I didn’t know how to fix. Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thanks, /Staffan > > Dan > > > On 5/8/14 12:06 AM, Staffan Larsen wrote: >> All, >> >> This is a fix for an assert in JVMTI that verifies that JVMTI’s internal >> notion of the number of frames on the stack is correct. >> >> When running in -Xcomp mode and enable single-stepping (or >> method_entry/exit) we will revert all frames on the stack to be run by the >> interpreter. Only the interpreter can send single-step and >> method_entry/exit. However, if one of the frames is a native wrapper, that >> frame will not be reverted (presumably because we don't know how to do >> that). This will cause us to miss a method_exit event when that native frame >> is popped. This in turn will mess up the logic in JVMTI that keeps track of >> the number of frames currently on the stack (see >> JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >> >> The proposed solution is to include a method_exit event in the native >> wrapper frame if interpreted mode has been enabled. This needs updates to >> SharedRuntime::generate_native_wrapper() for all platforms. >> >> Kudos to Rickard for helping me write the code. >> >> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >> >> The fix has been verified by running the failing test in JPRT with -Xcomp. >> >> Thanks, >> /Staffan >
Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
Looks good! Thanks, /Staffan On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which contains > https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So > it seems to be time to push the fix for JDK-8034960. I've made a new webrev > to be sure the changes fit in in the latest jdk9 source. The webrev can be > found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > Thanks, > Katja > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: >> I’ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also added >> core-libs to the review thread. >> >> I’m sure you know this, but for the record: please don’t push this until >> jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 13:07, Yekaterina Kantserova >> wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >>> >>> When using @library in a JTreg test even @build need to be specify for all >>> library files used by the test. If @build is not specified it can lead to >>> intermittent failures when running tests concurrently, since javac implicit >>> compilation and @library and -concurrency don't play well together. >>> >>> Verified locally since no JTreg with fix has been promoted yet. >>> >>> >>> Thanks, >>> Katja >
Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
On 09/05/2014 11:43, Yekaterina Kantserova wrote: Hi, The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks for doing this, it should make concurrent test runs a lot more stable. I've skimmed over the changes and they look good to me too. -Alan
Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError
Staffan, Alan, thanks for reviews! I will wait with pushing it until Monday to make sure no one has objections. // Katja On 05/09/2014 01:07 PM, Alan Bateman wrote: On 09/05/2014 11:43, Yekaterina Kantserova wrote: Hi, The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks for doing this, it should make concurrent test runs a lot more stable. I've skimmed over the changes and they look good to me too. -Alan
Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thumbs up! src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp Thanks for fixing the entry type. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. Dan On 5/9/14 4:47 AM, Staffan Larsen wrote: On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( I'm not sure that JRT_LEAF is right. I would think that JvmtiExport::post_method_exit() would have to grab one or more locks with all the state checks it has to make... For reference, InterpreterRuntime::post_method_exit() is a wrapper around JvmtiExport::post_method_exit() and it is IRT_ENTRY instead of IRT_LEAF. Good catch! src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. I'm guessing that PPC has the same issue, but I'm presuming that someone else (Vladimir?) will handle that… Yes, I was hoping that I could file a follow-up bug for the platforms I didn’t know how to fix. Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thanks, /Staffan Dan On 5/8/14 12:06 AM, Staffan Larsen wrote: All, This is a fix for an assert in JVMTI that verifies that JVMTI’s internal notion of the number of frames on the stack is correct. When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. Kudos to Rickard for helping me write the code. webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ bug:https://bugs.openjdk.java.net/browse/JDK-8041934 The fix has been verified by running the failing test in JPRT with -Xcomp. Thanks, /Staffan
RFR: 8041923 Command line output is missing from jinfo
Before the fix of JDK-8036599 the jinfo -flags output contained:
Non-default VM flags: -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280
-XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=1572864
-XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
-XX:+UseParallelGC
Command line: -Xmx30m
After the fix it says only:
VM Flags:
-XX:CICompilerCount=3 -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280
-XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=10485760
-XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
-XX:+UseParallelGC
To restore the old output sun.tools.jinfo.JInfo has been modified to include
output from vm.executeJCmd("VM.command_line"); as well:
VM Flags:
-XX:CICompilerCount=3 -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280
-XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=10485760
-XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops
-XX:+UseParallelGC
VM Arguments:
jvm_args: -Xmx30m
java_command: Sleeper 1
java_class_path (initial): /Users/staffan/dev
Launcher Type: SUN_STANDARD
webrev: http://cr.openjdk.java.net/~sla/8041923/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8041923
Thanks,
/Staffan
Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync
Staffan, This is important discovery, thanks! The fix looks good to me. One question below. Thanks, Serguei On 5/9/14 3:47 AM, Staffan Larsen wrote: On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( I'm not sure that JRT_LEAF is right. I would think that JvmtiExport::post_method_exit() would have to grab one or more locks with all the state checks it has to make... For reference, InterpreterRuntime::post_method_exit() is a wrapper around JvmtiExport::post_method_exit() and it is IRT_ENTRY instead of IRT_LEAF. Good catch! Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? +__ call_VM_leaf( + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), + thread, rax); src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. I'm guessing that PPC has the same issue, but I'm presuming that someone else (Vladimir?) will handle that… Yes, I was hoping that I could file a follow-up bug for the platforms I didn’t know how to fix. Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thanks, /Staffan Dan On 5/8/14 12:06 AM, Staffan Larsen wrote: All, This is a fix for an assert in JVMTI that verifies that JVMTI’s internal notion of the number of frames on the stack is correct. When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. Kudos to Rickard for helping me write the code. webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041934 The fix has been verified by running the failing test in JPRT with -Xcomp. Thanks, /Staffan
RFR (S) 8042796: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8042796 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 Summary: This is a Nightly Stabilization issue that was caused by a combination of two problems: - A regression introduced by the fix of: https://bugs.openjdk.java.net/browse/JDK-7182152 - An SQE testbase infra regression: https://bugs.openjdk.java.net/browse/INTJDK-7611018 A number of the vm.mlvm tests hits this guarantee taht was added by 7182152 (must be relaxed). The issue is with the deleted static private methods that are still present in the CP cache. The fix is to mark the deleted methods with the flag JVM_ACC_IS_DELETED and then use it to relax the guarantee condition. Testing: Running the failing tests: vm.mlvm.indy.func.jvmti In progress: nsk.jvmti, nsk.jdi, java.lang.instrument test runs on sparcv9 and amd64. Thanks, Serguei
