JDK-8079353 : [TESTBUG] runtime/CompressedOops/UseCompressedOops.java failed on Windows when getting disjoint instead of zero based coops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2015-05-05
  • Updated: 2021-02-04
  • Resolved: 2019-02-15
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 12 JDK 13
12.0.2Fixed 13 b09Fixed
Related Reports
Duplicate :  
JDK-8141023 - win64: UseCompressedOops.java: 'Zero based' missing from stdout/stderr
Duplicate :  
JDK-8219591 - 'Zero based' missing from stdout/stderr
Duplicate :  
JDK-8219425 - runtime/CompressedOops/UseCompressedOops.java timeout on windows
Relates :  
JDK-8064457 - Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
Relates :  
JDK-8086003 - Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing
Sub Tasks
JDK-8141533 :  
[TESTBUG] Add @ignore to runtime/CompressedOops/UseCompressedOops.java until JDK-8079353 has been resolved - Resolved
JDK-8218579 :  
add hotspot/jtreg/runtime/CompressedOops/UseCompressedOops.java to ProblemList.txt - Resolved
Description
Failed in JPRT on Windows 2012R2:

heap address: 0x0000001000200000, size: 32768 MB, Compressed Oops mode: Non-zero disjoint base: 0x0000001000000000, Oop shift amount: 4, no protected page in front of the heap

Narrow klass base: 0x0000001800200000, Narrow klass shift: 0
Compressed class space size: 1073741824 Address: 0x0000001800200000 Req Addr: 0x0000001800200000
];
 stderr: [java version "1.9.0-internal-fastdebug"
Java(TM) SE Runtime Environment (build 1.9.0-internal-fastdebug-20150505091111.stefank.hs-gc-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-20150505091111.stefank.hs-gc-b00, mixed mode)
]
 exitValue = 0

java.lang.RuntimeException: 'Zero based' missing from stdout/stderr 

	at com.oracle.java.testlibrary.OutputAnalyzer.shouldContain(OutputAnalyzer.java:134)
	at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:124)
	at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:54)
	at UseCompressedOops.main(UseCompressedOops.java:41)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:502)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
	at java.lang.Thread.run(Thread.java:745)
Comments
11u variant [on hold]: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004866.html
04-02-2021
Fix Request Fixing this bug in JDK-12u will prevent this test from intermittently failing on Windows. The fix avoids running test cases on Windows that could fail because of ASLR. The fix is low risk because only the test itself is changed. The changed test was run 500+ times on Windows and also tested on other platforms. The patch for the test applied cleanly.
28-02-2019
If the base is 0x18oooo0000, and the shift is 3, the VM runs in the mode disjoint_heap_base. That means, that it can do base & (cOop<<3) for decoding. This allows optimizations, which are implemented on ppc for example. In case of "Non-zero based" the decoding must use '+' instead of '&': base + (cOop << 3). If the base was 0x18o1oo0000, you could not use '&' and it would be a true "Non-zero based" heap. Still, this seems a test error, but not in the logic of the test. The test tries to force the VM to put the heap at an address where "Non-zerro based" is needed by setting HeapBaseMinAddress. This seems to fail.
13-02-2019
The above failure found by David looks like a test error. The compressed oops base is 0x1800000000. The test for disjoint base is: static bool is_disjoint_heap_base_address(address addr) { return (((uint64_t)(intptr_t)addr) & (((uint64_t)UCONST64(0xFFFFffffFFFFffff)) >> (32-LogMinObjAlignmentInBytes))) == 0; } LogMinObjAlignmentInBytes is 3, so 0xFFFFffffFFFFffff >> 27 = 0x7FFFffffF This computes to 0x1800000000 & 0x7FFFffffF which equals 0. So, is_disjoint_heap_base_address() returns TRUE causing the test to fail.
12-02-2019
Possibly multiple issues here. From mach5-one-jdk13-jdk-319-tier3-20190205-2121-362849 ----------System.err:(31/2034)---------- java version "13-internal" 2019-09-17 Java(TM) SE Runtime Environment (fastdebug build 13-internal+0-jdk13-jdk.319) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 13-internal+0-jdk13-jdk.319, mixed mode) stdout: [[0.004s][warning][arguments] -XX:+PrintCompressedOopsMode is deprecated. Will use -Xlog:gc+heap+coops=info instead. [0.021s][info ][gc,heap,coops] Heap address: 0x0000001800200000, size: 32 MB, Compressed Oops mode: Non-zero disjoint base: 0x0000001800000000, Oop shift amount: 3 ]; stderr: [Java HotSpot(TM) 64-Bit Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory. java version "13-internal" 2019-09-17 Java(TM) SE Runtime Environment (fastdebug build 13-internal+0-jdk13-jdk.319) Java HotSpot(TM) 64-Bit Server VM (fastdebug build 13-internal+0-jdk13-jdk.319, mixed mode, sharing) ] exitValue = 0 java.lang.RuntimeException: 'Non-zero based' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:151) at UseCompressedOops.testCompressedOopsModes(UseCompressedOops.java:122) at UseCompressedOops.testCompressedOopsModesGCs(UseCompressedOops.java:58) at UseCompressedOops.main(UseCompressedOops.java:48) This error relates to "Non-zero based" expected but what we see is " Non-zero disjoint base".
06-02-2019
Now being seen in tier1 testing - priority bumped to P2. Either needs fixing or problem-listing again.
01-02-2019
Seen twice in random testing today after I removed the test from the problemList yesterday.
25-01-2019
Ran 10000 iterations on Windows 2012R2 x64 with no failures. Closing as CNR.
30-03-2018
ILW MLL = P5 I: Medium, Noise in our testing L: Low, Rare W: Low, Except for noise in our testing, the end user impact is non-existent
18-04-2016
Hi, it's very unlikely that the disjoint based change has something to do with this. The failing tests tries to allocate 32GB heap below the 64GB boundary. If there is some other stuff allocated around the address '32GB', this will fail. You have to check who places that data there. I would assume this is a problem of the OS. I know Microsoft changed the memory allocation because we had a problem on 32-bit Windows 2012R2: A test that used 1.8GB would not start any more because Windows placed the codecache differently than before, so that nowhere 1.8 adjacent GB were free. We had that bug fixed by Microsoft. But that was 32-bit only.
10-11-2015
I can reproduce this about 1 in 500 runs, we're not able to allocate at the 32gb boundary due to Windows ASLR putting CRT heap and thread stacks there, not sure if the disjoint change is to blame here. I need to see what happened pre-disjoint.
10-11-2015
Changed to P2, as this has shown up more frequently in JPRT. At least 3 times in the past week.
02-11-2015