JDK-8192871 : Solaris: TestAllocateHeapAt fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 10
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris
  • CPU: sparc
  • Submitted: 2017-12-01
  • Updated: 2020-06-30
  • Resolved: 2020-06-30
Related Reports
Relates :  
JDK-8190308 - Implementation: JEP 316: Heap Allocation on Alternative Memory Devices
Relates :  
JDK-8194142 - Solaris 10 no longer working after 8190308
Relates :  
JDK-8193105 - Print error code when map_memory_to_file() fails
Description
From a JPRT run on Solaris sparcv9:

STDOUT:
Testing:
/opt/jprt/T/T1/013053.daholme/testproduct/solaris_sparcv9_5.11-fastdebug/bin/java -Duser.home=/opt/jprt/T/T1/013053.daholme -Djava.io.tmpdir=/opt/jprt/T/T1/013053.daholme/io/solaris_sparcv9_5.11-fastdebug-c2-hotspot_tier1_gc_2 -server -XX:AllocateHeapAt=. -Xlog:gc+heap=info -Xmx32m -Xms32m -version
Command line: [/opt/jprt/T/T1/013053.daholme/testproduct/solaris_sparcv9_5.11-fastdebug/bin/java -cp /opt/jprt/T/T1/013053.daholme/s/closed/test/hotspot/testoutput/hotspot_tier1_gc_2/JTwork/hotspot_jtreg_0/classes/0/gc/TestAllocateHeapAt.d:/opt/jprt/T/T1/013053.daholme/s/open/test/hotspot/jtreg/gc:/opt/jprt/T/T1/013053.daholme/s/closed/test/hotspot/testoutput/hotspot_tier1_gc_2/JTwork/hotspot_jtreg_0/classes/0/test/lib:/opt/jprt/jib-data/install/java/re/jtreg/4.2/promoted/all/b10/bundles/jtreg_bin-4.2.zip/jtreg/lib/javatest.jar:/opt/jprt/jib-data/install/java/re/jtreg/4.2/promoted/all/b10/bundles/jtreg_bin-4.2.zip/jtreg/lib/jtreg.jar -Duser.home=/opt/jprt/T/T1/013053.daholme -Djava.io.tmpdir=/opt/jprt/T/T1/013053.daholme/io/solaris_sparcv9_5.11-fastdebug-c2-hotspot_tier1_gc_2 -server -XX:AllocateHeapAt=. -Xlog:gc+heap=info -Xmx32m -Xms32m -version ]
Output:
[0.033s][info][gc,heap] Heap region size: 1M
Error occurred during initialization of VM
Error in mapping Java heap at the given filesystem directory.

STDERR:
 stdout: [[0.033s][info][gc,heap] Heap region size: 1M
Error occurred during initialization of VM
Error in mapping Java heap at the given filesystem directory.
];
 stderr: []
 exitValue = 1

java.lang.RuntimeException: 'Successfully allocated Java heap at location' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:135)
	at TestAllocateHeapAt.main(TestAllocateHeapAt.java:65)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:230)
	at java.base/java.lang.Thread.run(Thread.java:844)
Comments
Solaris/sparc platform has been removed with JDK-8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports
30-06-2020
It also seems that posix_fallocate depends on the filesystem more so, or as much as the OS: http://austingroupbugs.net/view.php?id=684&nbn=10
23-12-2017
Exit with the reported error message occurs from map_memory_to_file, in response to a failed util_posix_fallocate. (There is a very similar message generated by reserve_memory_aligned, in response to a failed call to replace_existing_mapping_with_file_mapping, which returns the result of map_memory_to_file, which has additional fail paths based on mmap result. However, that message doesn't have a trailing period, while the cut-and-paste report in the description above does have a trailing period, as does the message for failed util_posix_fallocate. It would be helpful to be more easily able to distinguish between those; the presence or absence of a period is kind of subtle.) In the case of a failed util_posix_fallocate, it would be helpful to report the error code. The Solaris man page for posix_fallocate lists a number of interesting errors not listed in the Linux man page, including EAGAIN and EINTR. Not retrying for either of those might be the problem.
06-12-2017
I agree that reporting the error code from util_posix_fallocate() is helpful, so I already filed JDK-8193105 and working on it. Added link to it as well.
06-12-2017
[~dholmes] Thanks for the log link. I agree with you that this would be resource shortage error we see on Sparc comment. I don't have any clue but as my test runs were okay, I'm thinking non-vm issue. Or this could be just very intermittent failure. >> could it be relying on Linux behaviour? I don't think so because my test runs on Solaris was good. But it would be good to investigate whether or not used flags for mmap[1] would result in this failure. Solaris didn't have any compile problem with MAP_NORESERVE and MAP_ANONYMOUS though. [1]: non-portable codes are pointed out at JDK-8192898 (AIX build broken after JDK-8190308) and JDK-8192919 (Refactor os_posix.cpp to remove non-portable flags).
06-12-2017
The reported failures are on different hosts, so it's not a single machine configuration problem or similar.
02-12-2017
Need to examine exactly how the code tries to set up the mapping. It's already been pointed out that the os_posix.cpp code is not in fact posix compliant - could it be relying on Linux behaviour? It's also possible this is an alternate manifestation of the resource shortage errors we see on sparc.
02-12-2017
I ran the test for 100 iterations on Solaris Sparc with fastdebug / product, but no luck to reproduce. Originally reported with fastdebug. Another test of 100 iterations on Windows-x64, Linux-X64 and OSX with fastdebug / product is also okay. [Updated] all tests above was ran by Mach5 not JPRT. Additional test of 100 iterations on Solaris Sparc - fastdebug was okay.
01-12-2017
This may be an intermittent failure of the JDK-8190308 feature, so far only seen on Solaris SPARC.
01-12-2017