JDK-8211956 was recently reported with the usage of jruby. When both 'oa0' and 'oa1' archive heap spaces are created at dump time, the VM crashes when mapping the archive heap regions. With a JDK 12 debug binary, it fails with following assert:

# after -XX: or in .hotspotrc:  SuppressErrorAt=/filemap.hpp:166
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/export/users/jiangli/jdk12/open/src/hotspot/share/memory/filemap.hpp:166), pid=23161, tid=23162
#  assert(i >= 0 && i < 9) failed: invalid region
#
# JRE version:  (12.0) (slowdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 12-internal+0-2018-10-09-0504378.jianzhou.jdk12, mixed mode, aot, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c" (or dumping to /export/users/jiangli/jruby/jruby-startup-master/core.23161)
#
# An error report file with more information is saved as:
# /export/users/jiangli/jruby/jruby-startup-master/hs_err_pid23161.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

When the size of archived java heap data is larger than one dump-time GC region, multiple GC regions are used for the archived heap data. The lowest GC region that's partially filled is written as a separate archive heap space ('st1' and 'oa1'). Apparently this is an insufficiently tested area. We need to create a stress test that creates large number archived java objects triggers the usage of 'st1' and 'oa1'.