RFR: 8286066: FillerObject_klass should be loaded as early as possible

[Jie Fu]

Hi all,

`FillerObject_klass` was loaded too late, which may lead to VM crash due to `FillerObject_klass` is unloaded.
We found this bug by running `runtime/cds/appcds/TestEpsilonGCWithCDS.java` on x86_32.

>From the following gdb backtrace, `FillerObject_klass` may be used during `vmClasses::resolve_all` (see frame #27 resolving `Exception_klass`).
So `FillerObject_klass` should be loaded as soon as possible.


(gdb) bt
#0  0xf66c5506 in vmClasses::check_klass (k=0x0) at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55
#1  0xf68de7a7 in vmClasses::FillerObject_klass () at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:87
#2  0xf695ce9e in CollectedHeap::fill_with_object_impl (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:470
#3  0xf695b40b in CollectedHeap::fill_with_object (start=0xb2e370c8, words=2, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:479
#4  0xf695bf4e in CollectedHeap::fill_with_object (start=0xb2e370c8, end=0xb2e370d0, zap=true) at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.hpp:289
#5  0xf695b4fd in CollectedHeap::fill_with_dummy_object (this=0xf602c250, start=0xb2e370c8, end=0xb2e370d0, zap=true)
    at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.cpp:503
#6  0xf71d5866 in ThreadLocalAllocBuffer::insert_filler (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:122
#7  0xf71d5949 in ThreadLocalAllocBuffer::retire (this=0xf6017cdc, stats=0x0) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:145
#8  0xf71d5995 in ThreadLocalAllocBuffer::retire_before_allocation (this=0xf6017cdc) at /home/jdk/src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp:152
#9  0xf6ed49c0 in MemAllocator::allocate_inside_tlab_slow (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:309
#10 0xf6ed48ea in MemAllocator::allocate_inside_tlab (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:278
#11 0xf6ed4b47 in MemAllocator::mem_allocate (this=0xf62255c0, allocation=...) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:350
#12 0xf6ed4b9e in MemAllocator::allocate (this=0xf62255c0) at /home/jdk/src/hotspot/share/gc/shared/memAllocator.cpp:363
#13 0xf6c1b199 in CollectedHeap::class_allocate (this=0xf602c250, klass=0xaa41bca8, size=26, __the_thread__=0xf6017c10)
    at /home/jdk/src/hotspot/share/gc/shared/collectedHeap.inline.hpp:46
#14 0xf6c1aead in InstanceMirrorKlass::allocate_instance (this=0xaa41bca8, k=0xaa429d70, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/oops/instanceMirrorKlass.cpp:55
#15 0xf6c396b5 in java_lang_Class::create_mirror (k=0xaa429d70, class_loader=..., module=..., protection_domain=..., classData=..., __the_thread__=0xf6017c10)
    at /home/jdk/src/hotspot/share/classfile/javaClasses.cpp:1004
#16 0xf690c541 in ClassFileParser::fill_instance_klass (this=0xf62257d4, ik=0xaa429d70, changed_by_loadhook=false, cl_inst_info=..., __the_thread__=0xf6017c10)
    at /home/jdk/src/hotspot/share/classfile/classFileParser.cpp:5428


    ....


#27 0xf724e3ea in vmClasses::resolve (id=vmClassID::Exception_klass_knum, __the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:99


#28 0xf724e4ed in vmClasses::resolve_until (limit_id=vmClassID::SoftReference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10)
    at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:108
#29 0xf724ef3f in vmClasses::resolve_through (last_id=vmClassID::Reference_klass_knum, start_id=@0xf6225fa8: vmClassID::Cloneable_klass_knum, __the_thread__=0xf6017c10)
    at /home/jdk/src/hotspot/share/classfile/vmClasses.hpp:64
#30 0xf724e75e in vmClasses::resolve_all (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/vmClasses.cpp:168
#31 0xf718845a in SystemDictionary::initialize (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/classfile/systemDictionary.cpp:1655
#32 0xf71f9814 in Universe::genesis (__the_thread__=0xf6017c10) at /home/jdk/src/hotspot/share/memory/universe.cpp:346
#33 0xf71fb851 in universe2_init () at /home/jdk/src/hotspot/share/memory/universe.cpp:966
#34 0xf6c07275 in init_globals () at /home/jdk/src/hotspot/share/runtime/init.cpp:132
#35 0xf71cc844 in Threads::create_vm (args=0xf622626c, canTryAgain=0xf62261d3) at /home/jdk/src/hotspot/share/runtime/thread.cpp:2756


The fix just loads `FillerObject` after `Object_klass`.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8286066: FillerObject_klass should be loaded as early as possible

Changes: https://git.openjdk.java.net/jdk/pull/8519/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8519&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286066
  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8519.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8519/head:pull/8519

PR: https://git.openjdk.java.net/jdk/pull/8519