-
Bug
-
Resolution: Fixed
-
P2
-
9
-
MacOSX(10.9)
-
b42
-
generic
-
os_x
-
Verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8083499 | emb-9 | Calvin Cheung | P2 | Resolved | Fixed | team |
| JDK-8252306 | openjdk8u272 | Calvin Cheung | P2 | Resolved | Fixed | b05 |
| JDK-8248944 | 8u271 | David Buck | P2 | Resolved | Fixed | b01 |
| JDK-8242254 | 8u261 | David Buck | P2 | Closed | Fixed | b02 |
| JDK-8244884 | 8u251 | David Buck | P2 | Resolved | Fixed | b34 |
| JDK-8251622 | emb-8u271 | David Buck | P2 | Resolved | Fixed | team |
| JDK-8246887 | emb-8u261 | David Buck | P2 | Resolved | Fixed | team |
Testsuite name: hotspot
Test name(s): runtime/SharedArchiveFile/LimitSharedSizes.java
Product(s) tested: jdk 9 fcs new compiler
OS/architecture: MacOSX(10.9)
Reproducible: Always
Reproducible on machine: stt-mac-01.ru.oracle.com
Also reproducible on machine: stt-mac-05.ru.oracle.com, stt-mac-08.ru.oracle.com
Is it a test bug or a product bug : Product Bug
Is it a Regression: Yes
Regression introduced in release/build: JDK 9 fcs new compiler
Is it a platform specific issue: Yes
----------System.err:(36/1864)----------
stdout: [Allocated shared space: 25288704 bytes at 0x0000000800000000
Loading classes to share ...
Loading classes to share: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Number of classes 118
instance classes = 104
obj array classes = 6
type array classes = 8
Calculating fingerprints ... done.
Removing unshareable information ... done.
ro space: 502048 [ 34.4% of total] out of 4194304 bytes [12.0% used] at 0x0000000800000000
rw space: 605808 [ 41.5% of total] out of 16777216 bytes [ 3.6% used] at 0x0000000800400000
md space: 316912 [ 21.7% of total] out of 4194304 bytes [ 7.6% used] at 0x0000000801400000
mc space: 34053 [ 2.3% of total] out of 122880 bytes [27.7% used] at 0x0000000801800000
total : 1458821 [100.0% of total] out of 25288704 bytes [ 5.8% used]
];
stderr: []
exitValue = 0
java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
at com.oracle.java.testlibrary.OutputAnalyzer.shouldContain(OutputAnalyzer.java:80)
at LimitSharedSizes.main(LimitSharedSizes.java:82)
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:498)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:745)
JavaTest Message: Test threw exception: java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
JavaTest Message: shutting down test
STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
Test run log location:
Steps to reproduce:
1. login into stt-mac-01.ru.oracle.com
2. go to /export/home/gtee/9b90_hotspot
3. add test case in 'failedcase' file
4. run : python filereader.py
workspace : http://jre.us.oracle.com/java/re/scanas412/java_re2/archive/jdk9-build-upgrades/b90_2014-09-10-1604_32/ws/hotspot/test/
jdk : http://jre.us.oracle.com/java/re/scanas412/java_re2/archive/jdk9-build-upgrades/b90_2014-09-10-1604_32/bundles/macosx-amd64/
Test name(s): runtime/SharedArchiveFile/LimitSharedSizes.java
Product(s) tested: jdk 9 fcs new compiler
OS/architecture: MacOSX(10.9)
Reproducible: Always
Reproducible on machine: stt-mac-01.ru.oracle.com
Also reproducible on machine: stt-mac-05.ru.oracle.com, stt-mac-08.ru.oracle.com
Is it a test bug or a product bug : Product Bug
Is it a Regression: Yes
Regression introduced in release/build: JDK 9 fcs new compiler
Is it a platform specific issue: Yes
----------System.err:(36/1864)----------
stdout: [Allocated shared space: 25288704 bytes at 0x0000000800000000
Loading classes to share ...
Loading classes to share: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Number of classes 118
instance classes = 104
obj array classes = 6
type array classes = 8
Calculating fingerprints ... done.
Removing unshareable information ... done.
ro space: 502048 [ 34.4% of total] out of 4194304 bytes [12.0% used] at 0x0000000800000000
rw space: 605808 [ 41.5% of total] out of 16777216 bytes [ 3.6% used] at 0x0000000800400000
md space: 316912 [ 21.7% of total] out of 4194304 bytes [ 7.6% used] at 0x0000000801400000
mc space: 34053 [ 2.3% of total] out of 122880 bytes [27.7% used] at 0x0000000801800000
total : 1458821 [100.0% of total] out of 25288704 bytes [ 5.8% used]
];
stderr: []
exitValue = 0
java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
at com.oracle.java.testlibrary.OutputAnalyzer.shouldContain(OutputAnalyzer.java:80)
at LimitSharedSizes.main(LimitSharedSizes.java:82)
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:498)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:745)
JavaTest Message: Test threw exception: java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
JavaTest Message: shutting down test
STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'The shared read only space is not large enough' missing from stdout/stderr
Test run log location:
Steps to reproduce:
1. login into stt-mac-01.ru.oracle.com
2. go to /export/home/gtee/9b90_hotspot
3. add test case in 'failedcase' file
4. run : python filereader.py
workspace : http://jre.us.oracle.com/java/re/scanas412/java_re2/archive/jdk9-build-upgrades/b90_2014-09-10-1604_32/ws/hotspot/test/
jdk : http://jre.us.oracle.com/java/re/scanas412/java_re2/archive/jdk9-build-upgrades/b90_2014-09-10-1604_32/bundles/macosx-amd64/
- backported by
-
JDK-8083499 Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Resolved
-
(2 backported by, 1 duplicates, 2 relates to)
[JDK-8060721] Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8666e625f2a4
User: lana
Date: 2014-12-10 19:54:57 +0000
User: lana
Date: 2014-12-10 19:54:57 +0000
URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/8666e625f2a4
User: ccheung
Date: 2014-11-10 19:44:50 +0000
User: ccheung
Date: 2014-11-10 19:44:50 +0000
This particular OSX C compiler optimization is compiling
strcat(class_list_path_str, "lib");
into:
000000000043a206 movq %r14, %rdi // rdi=&class_list_path_str
000000000043a209 callq 0x5b2e72 // <strlen> -> %RAX
000000000043a20e movl $0x62696c, -0x460(%rbp,%rax) // $0x62696c = {'l', 'i', 'b', '\0'}
Note that 0x0062696c is represented in memory as 0x6c, 0x69, 0x62, 0x00, because x64 is little endian.
Without this optimization, the generated code would simply call into strcat() and pass "lib" as a parameter. Because strcat() doesn't know how long the parameter string is, it need to have a loop that iterates over the string and append one character at a time.
With this optimization, because "lib" is very short, it can be appended by a single "movl" instruction. So this is faster than calling strcat.
Now, why does the compiler leave out these two lines?
strcat(class_list_path_str, os::file_separator());
strcat(class_list_path_str, "classlist");
I am not sure.
strcat(class_list_path_str, "lib");
into:
000000000043a206 movq %r14, %rdi // rdi=&class_list_path_str
000000000043a209 callq 0x5b2e72 // <strlen> -> %RAX
000000000043a20e movl $0x62696c, -0x460(%rbp,%rax) // $0x62696c = {'l', 'i', 'b', '\0'}
Note that 0x0062696c is represented in memory as 0x6c, 0x69, 0x62, 0x00, because x64 is little endian.
Without this optimization, the generated code would simply call into strcat() and pass "lib" as a parameter. Because strcat() doesn't know how long the parameter string is, it need to have a loop that iterates over the string and append one character at a time.
With this optimization, because "lib" is very short, it can be appended by a single "movl" instruction. So this is faster than calling strcat.
Now, why does the compiler leave out these two lines?
strcat(class_list_path_str, os::file_separator());
strcat(class_list_path_str, "classlist");
I am not sure.
So to summarize:
1) This bug (JDK-8060721) will result in some reduced performance on the Mac platform. It will not stop Mac development in the short term.
2) The main concern is that the assumed clang bug behind this problem may cause us other, as of yet undiscovered, problems.
Given this, I believe the best course of action is to proceed with the Mac compiler upgrade as is. This will not cause major problems to our Mac development effort,it will increase the likelihood of other potential problems being flushed out and it will drive us to find a solution to this problem more quickly.
1) This bug (
2) The main concern is that the assumed clang bug behind this problem may cause us other, as of yet undiscovered, problems.
Given this, I believe the best course of action is to proceed with the Mac compiler upgrade as is. This will not cause major problems to our Mac development effort,it will increase the likelihood of other potential problems being flushed out and it will drive us to find a solution to this problem more quickly.
Calvin writes via email:
> So without the CDS functionality, does it just mean we use more memory on the Mac for awhile?
For single java process, the footprint should be about the same.
It may affect startup perf too. Since I didn't see any bug reports from outside about CDS on Mac, I doubted it has a big impact.
> So without the CDS functionality, does it just mean we use more memory on the Mac for awhile?
For single java process, the footprint should be about the same.
It may affect startup perf too. Since I didn't see any bug reports from outside about CDS on Mac, I doubted it has a big impact.
Further investigation reveals that this problem also reproducible with Xcode 6.1 with fastdebug or release build.
I was testing with debug build with Xcode 6.1 and didn't see the problem.
This is due to the different optimization level used for debug build vs. release and fastdebug builds.
For debug build, the -O0 optimization level is being used.
For release and fastdebug builds, the -Os optimization level is being used.
I also have a simple patch for fixing this problem. The patch is getting rid of the const char* variable. See attached compiler_upgrade_patch.txt for details.
The patch works with Xcode 5.1.1 and 6.1 fastdebug and release builds.
I was testing with debug build with Xcode 6.1 and didn't see the problem.
This is due to the different optimization level used for debug build vs. release and fastdebug builds.
For debug build, the -O0 optimization level is being used.
For release and fastdebug builds, the -Os optimization level is being used.
I also have a simple patch for fixing this problem. The patch is getting rid of the const char* variable. See attached compiler_upgrade_patch.txt for details.
The patch works with Xcode 5.1.1 and 6.1 fastdebug and release builds.
I've raised the priority of this bug to P2. At today's JDK 9 RTeam meeting it was requested that we have an evaluation of this bug and a recommendation by next week's RTeam. I think the relevant questions are:
- What is the effect of this bug / test failure on the product?
- Is this a "build breaker" bug? In other words, does further Mac development on JDK 9 cease until this bug is resolved?
- What is the cost of implementing the workaround Calvin mentioned on 10/29 @ 12:10?
- Can we confirm with Apple that this is a known Xcode 5.1 bug?
We should remember that the plan of record is to update the compilers for JDK 9 at least once more before the release ships. We will move to Xcode 6.1 or later then. The question that needs to be answered now is not whether or not Xcode 6.1 is a good choice. It's whether or not we stay with gcc and Xcode 4.6.2 for now.
- What is the effect of this bug / test failure on the product?
- Is this a "build breaker" bug? In other words, does further Mac development on JDK 9 cease until this bug is resolved?
- What is the cost of implementing the workaround Calvin mentioned on 10/29 @ 12:10?
- Can we confirm with Apple that this is a known Xcode 5.1 bug?
We should remember that the plan of record is to update the compilers for JDK 9 at least once more before the release ships. We will move to Xcode 6.1 or later then. The question that needs to be answered now is not whether or not Xcode 6.1 is a good choice. It's whether or not we stay with gcc and Xcode 4.6.2 for now.
This seems to be a Xcode 5.1 compiler issue.
1) dissembling of the MetaspaceShare::preload_and_dump(TRAPS) showing the following 2 lines of code are missing:
strcat(class_list_path_str, os::file_separator());
strcat(class_list_path_str, "classlist");
(see attached disassembly.txt for details)
2) debugging with lldb, breakpoints couldn't be set in the above 2 lines of code.
It also shows that the first arg (class_list_path) passed into the MetaspaceShared::preload_and_dump(const char * class_list_path,
GrowableArray<Klass*>* class_promote_order,TRAPS) was incorrect.
It contains the path up to the "jre/lib"; it should include the "classlist", i.e. ("jre/lib/classlist")
(see attached lldb_debug.txt for details)
Xcode 6.1 doesn't have this problem.
With Xcode 5.1, a workaround is to define those 2 lines of code in a function in a separate .cpp file.
At this point, we are considering upgrading to Xcode 6.1.
1) dissembling of the MetaspaceShare::preload_and_dump(TRAPS) showing the following 2 lines of code are missing:
strcat(class_list_path_str, os::file_separator());
strcat(class_list_path_str, "classlist");
(see attached disassembly.txt for details)
2) debugging with lldb, breakpoints couldn't be set in the above 2 lines of code.
It also shows that the first arg (class_list_path) passed into the MetaspaceShared::preload_and_dump(const char * class_list_path,
GrowableArray<Klass*>* class_promote_order,TRAPS) was incorrect.
It contains the path up to the "jre/lib"; it should include the "classlist", i.e. ("jre/lib/classlist")
(see attached lldb_debug.txt for details)
Xcode 6.1 doesn't have this problem.
With Xcode 5.1, a workaround is to define those 2 lines of code in a function in a separate .cpp file.
At this point, we are considering upgrading to Xcode 6.1.
I would like to backport this to 8u for parity with Oracle 8u271.
The original patch does not apply cleanly.
Code review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-August/012440.html