JDK-8187078 : -XX:+VerifyOops finds numerous problems when running JPRT
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9,10,11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-09-01
  • Updated: 2020-04-22
  • Resolved: 2018-09-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 11 JDK 12 Other
11.0.8-oracleFixed 12 b10Fixed openjdk8u252Fixed
Related Reports
Blocks :  
JDK-8161684 - [testconf] Add VerifyOops' testing into compiler tiers
Relates :  
JDK-8205118 - CodeStrings::copy() assertion caused by -XX:+VerifyOops -XX:+PrintStubCode
Description
-XX:+VerifyOops finds numerous problems when running JPRT.

One reproducer:
jtreg -jdk:../build/slowdebug/jdk -va -nr test/compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java
Comments
Fix Request (8u) Same rationale as for 11u. Patch does not apply cleanly due to code moves. 8u RFR (reviewed by andrew): https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011203.html
20-02-2020
Fix Request (11u) This resolves some of the problems with -XX:+VerifyOops, which makes diagnostics more reliable. Patch applies cleanly to 11u, passes tier{1,2,3} tests. tier1 test with -XX:+VerifyOops improves, but still has lingering failures in AOT tests.
19-02-2020
I am seeing the similar failure with G1 and Shenandoah in 8u, due to missing T_OBJECT -> T_METADATA change in LIRGenerator::do_UnsafeGetObject (similar to barrierSetC1 hunk).
18-02-2020
Hi [~dlong], Please go ahead. Thank you.
20-08-2018
[~rraghavan] Do you mind if I take this one?
17-08-2018
ILW = Verification fails due to invalid oop, several tests with debug flag -XX:+VerifyOops, no workaround = MLH = P4 This initial ILW assumes that the problem does not affect product builds which is not clear yet. Please update if appropriate.
05-09-2017
Similarly, the usage of T_OBJECT is suspicious in: void LIRGenerator::do_ProfileCall(ProfileCall* x) { // Need recv in a temporary register so it interferes with the other temporaries LIR_Opr recv = LIR_OprFact::illegalOpr; LIR_Opr mdo = new_register(T_OBJECT); // tmp is used to hold the counters on SPARC LIR_Opr tmp = new_pointer_register();
05-09-2017
This seems to be one of the bugs: --- diff --git a/src/share/vm/c1/c1_LIRGenerator.cpp b/src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp +++ b/src/share/vm/c1/c1_LIRGenerator.cpp @@ -2393,7 +2393,7 @@ __ cmp(lir_cond_equal, src.result(), LIR_OprFact::oopConst(NULL)); __ branch(lir_cond_equal, T_OBJECT, Lcont->label()); } - LIR_Opr src_klass = new_register(T_OBJECT); + LIR_Opr src_klass = new_register(T_METADATA); if (gen_type_check) { // We have determined that offset == referent_offset && src != null. // if (src->_klass->_reference_type == REF_NONE) -> continue --- This fixes the JDKInternalMiscUnsafeAccessTestObject.java failure.
05-09-2017
Uploaded one hs_err file showing one of the reported bugs.
01-09-2017