Open CH3CHO opened 8 months ago
This issue seems to be related to this one https://github.com/oracle/graal/issues/4822, so I will ask the same question posted there:
What was your working directory and how many subfolders does it contain? Native Image scans all the folders in the current working directory to find classes that should be on the classpath. If this folder is large, especially on network drives, this can take some time. This behavior is going to change in the future, but it requires significant changes to the image builder.
Is this your case? There is already a fix for the ticket I shared before. But I think is important to see if this is a similar scenario.
This issue seems to be related to this one #4822, so I will ask the same question posted there:
What was your working directory and how many subfolders does it contain? Native Image scans all the folders in the current working directory to find classes that should be on the classpath. If this folder is large, especially on network drives, this can take some time. This behavior is going to change in the future, but it requires significant changes to the image builder.
Is this your case? There is already a fix for the ticket I shared before. But I think is important to see if this is a similar scenario.
It is a single-module maven project, so the structure is very simple. And I use the following command for building: mvn clean package native:compile-no-fork -P native -Dmaven.test.skip=true -U
Project structure:
.
├── mvnw
├── mvnw.cmd
├── native-deadlock.log
├── pom.xml
├── README.md
├── src
│ └── main
│ ├── java
│ │ └── com
│ │ └── xxxx
│ │ └── yyyy
│ │ └── testapp
│ │ ├── AppSpringBootConfiguration.java
│ │ ├── HomeController.java
│ │ └── ServletInitializer.java
│ └── resources
│ ├── application.properties
│ ├── logback.xml
│ └── META-INF
│ └── app.properties
└── tree.txt
is there a way you can create a minimal version of the project that can produce the same error?
I just found that after excluding an internal runtime dependency which depends on javaassist and objectasm (not sure if they are related), building process can complete successfully. However, since it's an internal library, I'm unable to share it here. But is it anyway to debug the building process, or see where does it get stuck?
And I'm using Oracle GraalVM now, because we need to use G1 GC. Should I try GraalCE to see if the problem is reproducible?
You can use the debugging tools explained here: https://www.graalvm.org/latest/reference-manual/native-image/debugging-and-diagnostics/DebugInfo/ Feel free to check if the problem persists in CE, if that is not the case, then we can reduce the scope of the issue to only Oracle GraalVM
, then we can reduce the scope of the issue to only Oracle GraalVM
Thanks for your help, Fernando.
I tried with GraalCE, and it worked normally.
❯ java -version
openjdk version "21.0.2" 2024-01-16
OpenJDK Runtime Environment GraalVM CE 21.0.2+13.1 (build 21.0.2+13-jvmci-23.1-b30)
OpenJDK 64-Bit Server VM GraalVM CE 21.0.2+13.1 (build 21.0.2+13-jvmci-23.1-b30, mixed mode, sharing)
However, the link you shared above seems to be related to "adding debug information to a generated native image". I'm not sure if it is helpful to this issue. And I will try to find if there is any verbose or debug flag in the native-image executable.
Just excluding org.javassist:javassist
can make it work. However, upgrading it to the latest version of 3.30.2-GA
doesn't.
I also tried to add --diagnostics-mode --verbose --native-image-info
arguments to native-image, but it looks like nothing more is output to the console.
In addition, it seems that only one thread in the ForkJoinPool is running during the building process. Does the following stacktrace ring a bell?
"ForkJoinPool-3-worker-8" Id=116 in RUNNABLE
at app/org.graalvm.collections/org.graalvm.collections.EconomicMapImpl.findHash(EconomicMapImpl.java:292)
at app/org.graalvm.collections/org.graalvm.collections.EconomicMapImpl.find(EconomicMapImpl.java:253)
at app/org.graalvm.collections/org.graalvm.collections.EconomicMapImpl.get(EconomicMapImpl.java:244)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.InterproceduralPartialEscapeAnalysisPhase$a.a(stripped:241)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:140)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:147)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:85)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d$$Lambda/0x00000007c29ad670.accept(Unknown Source)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.nodes.a.c(stripped:452)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.d.a(stripped:76)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.SubstratePolicyFactory$a.a(stripped:150)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.d.a(stripped:71)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.PriorityInliningPhase$a.d(stripped:582)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.PriorityInliningPhase$a.c(stripped:537)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.PriorityInliningPhase.d(stripped:474)
at app/com.oracle.graal.graal_enterprise/com.oracle.graal.phases.preciseinline.priorityinline.PriorityInliningPhase.a(stripped:469)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.SubstratePriorityInliningPhase.a(stripped:191)
at app/com.oracle.svm.svm_enterprise/com.oracle.svm.enterprise.hosted.phases.priorityinline.SubstratePriorityInliningPhase.run(stripped:76)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:434)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:322)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.phases.PhaseSuite.run(PhaseSuite.java:390)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:434)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:322)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.core.GraalCompiler.emitFrontEnd(GraalCompiler.java:294)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.core.GraalCompiler.compile(GraalCompiler.java:169)
at platform/jdk.internal.vm.compiler/org.graalvm.compiler.core.GraalCompiler.compileGraph(GraalCompiler.java:137)
at app/org.graalvm.nativeimage.builder/com.oracle.svm.hosted.code.CompileQueue.defaultCompileFunction(CompileQueue.java:1310)
at app/org.graalvm.nativeimage.builder/com.oracle.svm.hosted.code.CompileQueue$$Lambda/0x00000007c2aae408.compile(Unknown Source)
at app/org.graalvm.nativeimage.builder/com.oracle.svm.hosted.code.CompileQueue.doCompile(CompileQueue.java:1258)
at app/org.graalvm.nativeimage.builder/com.oracle.svm.hosted.code.CompileQueue$CompileTask.run(CompileQueue.java:306)
at app/org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.util.CompletionExecutor.executeCommand(CompletionExecutor.java:187)
at app/org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.util.CompletionExecutor.lambda$executeService$0(CompletionExecutor.java:171)
at app/org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.util.CompletionExecutor$$Lambda/0x00000007c238d648.run(Unknown Source)
at java.base@21.0.2/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1423)
at java.base@21.0.2/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)
at java.base@21.0.2/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)
at java.base@21.0.2/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)
at java.base@21.0.2/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)
at java.base@21.0.2/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)
What happens if you use -H:-AOTPriorityInline
to disable priority inlining?
Luckily (or saddly), after I cleaned my local Maven cache, the whole build process worked as expected.
I will keep tracking this problem. If it doesn't re-occur this week. I will close this issue. Thanks for your help.
-H:-AOTPriorityInline
The previous problem reoccurred today, and adding -H:-AOTPriorityInline
fixed it. Thanks, @fniephaus . However, does this option affect the runtime performance of the built native executable?
However, does this option affect the runtime performance of the built native executable?
Yes, it can affect the performance. I only suggested it as a workaround and to see whether it really is related to the priority inliner. Another test that shouldn't affect the performance as much is to use -H:-UseIPEA
. Could you try whether that fixes your problem as well?
Nonetheless, it would be great if you could provide us with a reproducer so we can take a closer look at what's going wrong. Thanks!
However, does this option affect the runtime performance of the built native executable?
Yes, it can affect the performance. I only suggested it as a workaround and to see whether it really is related to the priority inliner. Another test that shouldn't affect the performance as much is to use
-H:-UseIPEA
. Could you try whether that fixes your problem as well?Nonetheless, it would be great if you could provide us with a reproducer so we can take a closer look at what's going wrong. Thanks!
Thanks. I will try -H:-UseIPEA
. Since the cause is an internal library, I will see if I can remove all sensitive code and build a reproducer.
-H:-UseIPEA
works. I just check the documentation. It seems that UseIPEA
is a sub-option of AOTPriorityInline
. So are we narrowing the root cause?
Here is a minimal reproducer, deadlock.zip. Please try the following steps to reproduce this issue:
cd deadlock-agent
./mvnw clean install -Dmaven.test.skip
cd ../deadlock-reproducer
./mvnw clean package native:compile-no-fork -P native -Dmaven.test.skip
BTW, removing -march=x86-64-v2
from buildArgs can make it work.
It seems that UseIPEA is a sub-option of AOTPriorityInline. So are we narrowing the root cause?
Yes, that is correct.
BTW, removing -march=x86-64-v2 from buildArgs can make it work.
That's weird because it's defaulting to x86-64-v3
which uses more CPU features.
Shouldn't this be:
<buildArgs>
<buildArg>-march=x86-64-v2</buildArg>
<buildArg>--add-opens java.management/sun.management=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.lang=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.lang.reflect=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/sun.reflect.annotation=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.math=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.util=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/sun.util.calendar=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/sun.util.calendar=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.io=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.base/java.net=ALL-UNNAMED</buildArg>
<buildArg>--add-opens java.xml/com.sun.org.apache.xerces.internal.jaxp.datatype=ALL-UNNAMED</buildArg>
</buildArgs>
Oh, finally got the correct way of configuring multiple buildArgs....
Because some of our K8s nodes use a relatively old CPU architecture, we have to use v2, otherwise it won't work. And on my laptop with v3 support, using v3 can result a successful build, but using v2 can't.
Because some of our K8s nodes use a relatively old CPU architecture, we have to use v2, otherwise it won't work. And on my laptop with v3 support, using v3 can result a successful build, but using v2 can't.
Also when you configure multiple buildArgs correctly?
Also when you configure multiple buildArgs correctly?
No, it doesn't work, either.
And I tested all the -march
options supported on my AMD64 laptop. The result is as follows:
<!-- Goods -->
<!-- <buildArg>-march=native</buildArg>-->
<!-- <buildArg>-march=haswell</buildArg>-->
<!-- <buildArg>-march=skylake</buildArg>-->
<!-- <buildArg>-march=skylake-avx512</buildArg>-->
<!-- <buildArg>-march=x86-64-v4</buildArg>-->
<!-- <buildArg>-march=x86-64-v3</buildArg>-->
<!-- Bads -->
<!-- <buildArg>-march=x86-64-v2</buildArg>-->
<!-- <buildArg>-march=x86-64-v1</buildArg>-->
<!-- <buildArg>-march=x86-64</buildArg>-->
<!-- <buildArg>-march=compatibility</buildArg>-->
-march=list
result:
On AMD64, the following machine types are available:
'compatibility'
CPU features: all of 'x86-64'
'haswell'
CPU features: all of 'x86-64' + SSE3 + SSSE3 + SSE4_1 + SSE4_2 + POPCNT + LZCNT + AVX + AVX2 + AES + CLMUL + BMI1 + BMI2 + FMA
'native'
CPU features: CX8 + CMOV + FXSR + HT + MMX + AMD_3DNOW_PREFETCH + SSE + SSE2 + SSE3 + SSSE3 + SSE4A + SSE4_1 + SSE4_2 + POPCNT + LZCNT + TSC + TSCINV_BIT + AVX + AVX2 + AES + CLMUL + BMI1 + BMI2 + ADX + SHA + FMA + VZEROUPPER + FLUSH + FLUSHOPT + RDTSCP + RDPID + F16C
'skylake'
CPU features: all of 'haswell' + AMD_3DNOW_PREFETCH + ADX + FLUSHOPT
'skylake-avx512'
CPU features: all of 'skylake' + AVX512F + AVX512DQ + AVX512CD + AVX512BW + AVX512VL + CLWB
'x86-64'
CPU features: CX8 + CMOV + FXSR + MMX + SSE + SSE2
'x86-64-v1'
CPU features: all of 'x86-64'
'x86-64-v2'
CPU features: all of 'x86-64-v1' + SSE3 + SSSE3 + SSE4_1 + SSE4_2 + POPCNT
'x86-64-v3'
CPU features: all of 'x86-64-v2' + LZCNT + AVX + AVX2 + BMI1 + BMI2 + FMA
'x86-64-v4'
CPU features: all of 'x86-64-v3' + AVX512F + AVX512DQ + AVX512CD + AVX512BW + AVX512VL
Hi guys, any new findings on this issue? Thanks.
Update: It seems not to be related to the arch
option. Adding several dependencies can also result in the same error.
Describe the issue
Following error is shown when building a native image using Maven plugin.
Steps to reproduce the issue
Sorry, the project uses some internal libraries, so I can't share the entire project. Here are the configuration of native-maven-plugin.
Describe GraalVM and your environment:
More details