RFR: 8286066: FillerObject_klass should be loaded as early as possible [v2]

[David Holmes]

On Wed, 4 May 2022 01:25:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> That seems just a touch too early for my liking, Even though it is an empty class it is in a different package and that might perturb a few things in an unexpected way.
>>> 
>>> IIUC the class is going to be needed when the initial TLAB is expanded. Did you determine exactly which class was causing that? I'd like to see this loading delayed until after the core system classes, as much as possible.
>>> 
>>> Thanks.
>> 
>> 
>> 
>> Thanks @dholmes-ora for the review.
>> 
>> I added a jtreg to this bug.
>> It can also be reproduced with `java -XX:-UseCompressedClassPointers -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xshare:dump` on Linux/x64.
>> 
>> I saw the crash after `java.lang.ThreadDeath` was loaded on x86_32.
>> Maybe, we can load `FillerObject` after `java.lang.Error`.
>> 
>> STDERR:
>>  stdout: [[0.004s][info][class,path] bootstrap loader class path=/home/jdk/build/linux-x86-server-fastdebug/images/jdk/lib/modules
>> [0.006s][warning][gc,init   ] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
>> [0.006s][info   ][cds       ] Core region alignment: 4096
>> [0.006s][info   ][class,path] app loader class path=/home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar
>> [0.006s][info   ][class,path] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar
>> [0.006s][info   ][class,load] opened: /home/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_cds_appcds_TestEpsilonGCWithCDS_java/scratch/0/hello.jar
>> [0.010s][info   ][class,load] java.lang.Object source: jrt:/java.base
>> [0.010s][info   ][class,load] java.io.Serializable source: jrt:/java.base
>> [0.010s][info   ][class,load] java.lang.Comparable source: jrt:/java.base
>> [0.010s][info   ][class,load] java.lang.CharSequence source: jrt:/java.base
>> [0.010s][info   ][class,load] java.lang.constant.Constable source: jrt:/java.base
>> [0.010s][info   ][class,load] java.lang.constant.ConstantDesc source: jrt:/java.base
>> [0.011s][info   ][class,load] java.lang.String source: jrt:/java.base
>> [0.011s][info   ][class,load] java.lang.reflect.AnnotatedElement source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.reflect.GenericDeclaration source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.reflect.Type source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.invoke.TypeDescriptor source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.invoke.TypeDescriptor$OfField source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.Class source: jrt:/java.base
>> [0.012s][info   ][class,load] java.lang.Cloneable source: jrt:/java.base
>> [0.013s][info   ][class,load] java.lang.ClassLoader source: jrt:/java.base
>> [0.013s][info   ][class,load] java.lang.System source: jrt:/java.base
>> [0.013s][info   ][class,load] java.lang.Throwable source: jrt:/java.base
>> [0.013s][info   ][class,load] java.lang.Error source: jrt:/java.base
>> [0.013s][info   ][class,load] java.lang.ThreadDeath source: jrt:/java.base
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/vmClasses.hpp:55
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/jdk/src/hotspot/share/classfile/vmClasses.hpp:55), pid=78368, tid=78371
>> #  assert(k != __null) failed: klass not loaded
>> #
>> # JRE version:  (19.0) (fastdebug build )
>> # Java VM: OpenJDK Server VM (fastdebug 19-internal-adhoc..jdk, interpreted mode, tiered, epsilon gc, linux-x86)
>> # Problematic frame:
>> # V  [libjvm.so+0x85f54d]  CollectedHeap::fill_with_dummy_object(HeapWordImpl**, HeapWordImpl**, bool)+0x42d
>> #
>> 
>> 
>> What do you think?
>> Thanks.
>
>> Maybe, we can load `FillerObject` after `java.lang.Error`.
> 
> But I'm not sure if it's always safe to do so on any platforms.

For the x64 case (thanks for that reproducer!) it crashes after loading ` java.lang.Thread$UncaughtExceptionHandler` - so somewhat later than the x86 case.
I thought the underlying problem was the TLAB size but at least with EpsilonGC it is acting very counterintuitively - any size > 6K crashes, while less does not. But logging also seems to show that the requested size is not being honoured in those cases but the Ergo size of 2K is being selected! This is all very odd, but perhaps specific to Epsilon.
With G1 I can crash with a TLABSize of 4K (or less), but it occurs much later after loading `jdk.internal.reflect.UnsafeStaticFieldAccessorImpl` (for 4K). With 2K minimum TLABSize it is after `java.lang.Boolean`.
So I guess after Error is a reasonable compromise.
Thanks.

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

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