On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang <[email protected]> wrote:
>> We have seen crashes on many platforms (including x64) while running `make
>> run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java
>> JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`:
>>
>> SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557
>> V [libjvm.so+0x15bfe7a] MemAllocator::finish(HeapWordImpl**) const+0xca
>> (klass.inline.hpp:72)
>> V [libjvm.so+0x15c029f] ObjAllocator::initialize(HeapWordImpl**)
>> const+0x2f (memAllocator.cpp:391)
>> V [libjvm.so+0xb0630b] CollectedHeap::fill_with_object(HeapWordImpl**,
>> unsigned long, bool)+0x27b (collectedHeap.cpp:491)
>> V [libjvm.so+0x1c7a0bb]
>> ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b
>> (threadLocalAllocBuffer.cpp:118)
>> V [libjvm.so+0x15c0b14]
>> MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&)
>> const+0x84 (memAllocator.cpp:286)
>> V [libjvm.so+0x15c13ab]
>> MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb
>> (memAllocator.cpp:340)
>> V [libjvm.so+0x15c14f9] MemAllocator::allocate() const+0xa9
>> (memAllocator.cpp:353)
>> V [libjvm.so+0x1cc052e] TypeArrayKlass::allocate_common(int, bool,
>> JavaThread*)+0x13e (collectedHeap.inline.hpp:41)
>> V [libjvm.so+0x16fbc98] oopFactory::new_typeArray(BasicType, int,
>> JavaThread*)+0x38 (typeArrayKlass.hpp:51)
>> V [libjvm.so+0x106b0f3] java_lang_Class::restore_archived_mirror(Klass*,
>> Handle, Handle, Handle, JavaThread*)+0x413 (javaClasses.cpp:1246)
>> V [libjvm.so+0x14100bc] Klass::restore_unshareable_info(ClassLoaderData*,
>> Handle, JavaThread*)+0x66c (klass.cpp:903)
>> V [libjvm.so+0xfe2cb1]
>> InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle,
>> PackageEntry*, JavaThread*)+0x81 (instanceKlass.cpp:2823)
>> V [libjvm.so+0x1c0f5ad] SystemDictionary::preload_class(Handle,
>> InstanceKlass*, JavaThread*)+0x1ed (systemDictionary.cpp:1198)
>> V [libjvm.so+0x676e83]
>> AOTLinkedClassBulkLoader::preload_classes_in_table(Array<InstanceKlass*>*,
>> char const*, Handle, JavaThread*)+0x1a3 (aotLinkedClassBulkLoader.cpp:103)
>> V [libjvm.so+0x679af5]
>> AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165
>> (aotLinkedClassBulkLoader.cpp:76)
>> V [libjvm.so+0x67c371]
>> AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11
>> (aotLinkedClassBulkLoader.cpp:61)
>> V [libjvm.so+0x1d5bf30] vmClasses::resolve_all(JavaThread*)+0x3e0
>> (vmClasses.cpp:126)
>> V [libjvm.so+0x1c0f28c] SystemDictionary::initialize(JavaThread*)+0x10c
>> (systemDictionary.cpp:1623)
>> V [libjvm.so+0x1cc74ca] Uni...
>
>> ... make run-test
>> TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java
>> JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"
>
> I suspect the crash is caused by a preexisting issue that is exposed by this
> patch.
>
> In `vmClasses::resolve_all`:
>
> #if INCLUDE_CDS
> if (CDSConfig::is_using_aot_linked_classes()) {
> AOTLinkedClassBulkLoader::preload_classes(THREAD);
> }
> #endif
>
> // Preload commonly used klasses
> vmClassID scan = vmClassID::FIRST;
> // first do Object, then String, Class
> resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK);
> CollectedHeap::set_filler_object_klass(vmClasses::Object_klass());
>
>
> The filler-klass is not initialized when `preload_classes` is invoked, but
> `preload_classes` use heap-allocation, which may require filler-obj.
>
> @iklam What do you think?
@albertnetymk I've pushed https://github.com/openjdk/jdk/pull/28315. Please
verify if it fixes the crash before integrating this PR. Thanks!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3534185759
