Temp branch for merging JEP 483 into leyden/premain
Ashutosh Mehra
asmehra at redhat.com
Fri Nov 22 17:06:41 UTC 2024
>
> # Internal Error
>
> (/opt/mach5/mesos/work_dir/slaves/3fe4557b-066a-4392-9b05-ef874140c35c-S62/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/cfba4e4e-51a1-47f1-9d82-c6f09de94dd2/runs/e5810681-4ef9-46d2-9b14-5ef945fda550/workspace/open/src/hotspot/share/code/SCCache.cpp:4205),
> pid=1235, tid=1253
> # fatal error: Address 0x00007fe4817c5d30 for <unknown> is missing in
> SCA table
This error on Linux/x64 can be fixed by increasing MAX_STR_COUNT from 200
to 300.
Here is the patch for that:
diff --git a/src/hotspot/share/code/SCCache.cpp
b/src/hotspot/share/code/SCCache.cpp
index f42fab991a5..5df7a84f5d6 100644
--- a/src/hotspot/share/code/SCCache.cpp
+++ b/src/hotspot/share/code/SCCache.cpp
@@ -3956,7 +3956,7 @@ SCAddressTable::~SCAddressTable() {
}
}
-#define MAX_STR_COUNT 200
+#define MAX_STR_COUNT 300
static const char* _C_strings[MAX_STR_COUNT] = {nullptr};
static int _C_strings_count = 0;
static int _C_strings_s[MAX_STR_COUNT] = {0};
With this change
test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java#leyden
works fine.
On aarch64 (Linux or MacOS), this failure seems to affect many more test
> cases. Also, instead of <unknown>, we see
>
> # Internal Error (SCCache.cpp:4159), pid=87789, tid=28419
> # fatal error: Address 0x0000000114d4aa80 for
> Stub:_large_arrays_hashcode_boolean is missing in SCA table
I don't have an aarch64 machine, but the error message indicates some
stub(s) in cpu/aarch64/stubRoutines_aarch64.hpp are missing in the SCA
table.
I think adding them should resolve this issue. Patch for adding those stubs
is:
diff --git a/src/hotspot/share/code/SCCache.cpp
b/src/hotspot/share/code/SCCache.cpp
index f42fab991a5..89b5a8bf0e2 100644
--- a/src/hotspot/share/code/SCCache.cpp
+++ b/src/hotspot/share/code/SCCache.cpp
@@ -3813,6 +3813,11 @@ void SCAddressTable::init() {
SET_ADDRESS(_stubs, StubRoutines::aarch64::count_positives());
SET_ADDRESS(_stubs, StubRoutines::aarch64::count_positives_long());
SET_ADDRESS(_stubs, StubRoutines::aarch64::large_array_equals());
+ SET_ADDRESS(_stubs,
StubRoutines::aarch64::large_arrays_hashcode(T_BOOLEAN));
+ SET_ADDRESS(_stubs,
StubRoutines::aarch64::large_arrays_hashcode(T_BYTE));
+ SET_ADDRESS(_stubs,
StubRoutines::aarch64::large_arrays_hashcode(T_CHAR));
+ SET_ADDRESS(_stubs, StubRoutines::aarch64::large_arrays_hashcode(T_INT));
+ SET_ADDRESS(_stubs,
StubRoutines::aarch64::large_arrays_hashcode(T_SHORT));
SET_ADDRESS(_stubs, StubRoutines::aarch64::compare_long_string_LL());
SET_ADDRESS(_stubs, StubRoutines::aarch64::compare_long_string_UU());
SET_ADDRESS(_stubs, StubRoutines::aarch64::compare_long_string_LU());
@Ioi, can you please try these patches.
Thanks,
- Ashutosh Mehra
On Fri, Nov 22, 2024 at 12:27 AM <ioi.lam at oracle.com> wrote:
> As mentioned in today's Leyden meeting, I have merged JEP 483 into
> premain in my local repo. Since there are some new failures, I've put
> the merged version in a temporary branch:
>
> https://github.com/openjdk/leyden/tree/premain-temp-merge-after-jep-483
>
> [1] I have disabled some of the new CDS optimizations. See cdsConfig.cpp
>
> // FIXME -- leyden+JEP483 merge {
> FLAG_SET_ERGO(ArchiveDynamicProxies, false);
> FLAG_SET_ERGO(ArchiveLoaderLookupCache, false);
> FLAG_SET_ERGO(ArchivePackages, false);
> FLAG_SET_ERGO(ArchiveProtectionDomains, false);
> FLAG_SET_ERGO(ArchiveReflectionData, false);
>
> The reason is that JEP 483 is more aggressive in picking classes to be
> AOT-initialized. For example, with the -XX:+ArchiveProtectionDomains
> option, after the 483 merge, the jdk.internal.loader.NativeLibraries
> class is AOT-initialized. As a result, the static field
> nativeLibraryLockMap is archived, so it remembers all the native libs
> that were loaded during the assembly phase. When we attempt to load
> these libs again during production, we get an "is being loaded in
> another classloader" error.
>
> Therefore, we need more refactoring of the core libraries (such as
> adding runtimeSetup() methods) before some of these optimizations can be
> enabled again.
>
> [2] There's a new failure in the AOT compiler. Could someone familiar
> with the compiler take a look?
>
> # Internal Error
> (/opt/mach5/mesos/work_dir/slaves/3fe4557b-066a-4392-9b05-ef874140c35c-S62/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/cfba4e4e-51a1-47f1-9d82-c6f09de94dd2/runs/e5810681-4ef9-46d2-9b14-5ef945fda550/workspace/open/src/hotspot/share/code/SCCache.cpp:4205),
>
> pid=1235, tid=1253
> # fatal error: Address 0x00007fe4817c5d30 for <unknown> is missing in
> SCA table
>
> V [libjvm.so+0x366795] SCAddressTable::id_for_address(unsigned char*,
> RelocIterator, CodeBuffer*) [clone .part.0]+0x455 (SCCache.cpp:4205)
> V [libjvm.so+0x36df0a] SCCache::write_relocations(CodeBuffer*,
> unsigned int&)+0x68a (SCCache.cpp:4147)
> V [libjvm.so+0x3702d2] SCCache::write_nmethod(methodHandle const&,
> int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool,
> bool, bool, bool)+0xb92 (SCCache.cpp:3335)
> V [libjvm.so+0x3707b2] SCCache::store_nmethod(methodHandle const&,
> int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, CompLevel, bool, bool, bool,
> bool, bool, bool)+0x182 (SCCache.cpp:3102)
> V [libjvm.so+0x96ac99] ciEnv::register_method(ciMethod*, int,
> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, bool, bool, bool, bool,
> bool, bool, int, bool, SCCEntry*)+0xcf9 (ciEnv.cpp:1099)
> V [libjvm.so+0x161c22e] PhaseOutput::install_code(ciMethod*, int,
> AbstractCompiler*, bool, bool)+0x15e (output.cpp:3445)
> V [libjvm.so+0xa9f46b] Compile::Code_Gen()+0x5cb (compile.cpp:3036)
> V [libjvm.so+0xaa216f] Compile::Compile(ciEnv*, ciMethod*, int,
> Options, DirectiveSet*)+0x1c7f (compile.cpp:886)
> V [libjvm.so+0x8dfde1] C2Compiler::compile_method(ciEnv*, ciMethod*,
> int, bool, DirectiveSet*)+0x261 (c2compiler.cpp:172)
> V [libjvm.so+0xaaff07]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcb7
> (compileBroker.cpp:2626)
> V [libjvm.so+0xab2448] CompileBroker::compiler_thread_loop()+0x758
> (compileBroker.cpp:2272)
> V [libjvm.so+0xfac4ce] JavaThread::thread_main_inner()+0xee
> (javaThread.cpp:774)
>
> On Linux/x64, this can be reliably reproduced with
>
> test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java#leyden
>
> On aarch64 (Linux or MacOS), this failure seems to affect many more test
> cases. Also, instead of <unknown>, we see
>
> # Internal Error (SCCache.cpp:4159), pid=87789, tid=28419
> # fatal error: Address 0x0000000114d4aa80 for
> Stub:_large_arrays_hashcode_boolean is missing in SCA table
>
> Thanks
>
> - Ioi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20241122/a05d1da8/attachment.htm>
More information about the leyden-dev
mailing list