JDK-8060721 : Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic
  • Submitted: 2014-10-15
  • Updated: 2020-08-25
  • Resolved: 2014-11-10
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 8 JDK 9 Other
8u251Fixed 9 b42Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
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

 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/ 
Fix Request (8u) 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

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.

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.

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.

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'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.


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.

This problem doesn't reproduce with the latest promoted jdk9 b35. With the compiler upgrade build (b90), the vm doesn't read the classlist under the jre/lib dir when dumping a shared archive. Therefore, it only requires a very small read only space for the small number of shared classes. Since this test expects an error message 'The shared read only space is not large enough', it fails when the run completed without an error.

This test is passed in JDK 9 old compiler/platforms in MacOSX(10.9)