[Native Image] Generated .exe file exports way more symbols in GraalVM 25 - compared to GraalVM 24

[JaroslavTulach]

Describe the Issue

Enso is using so called "dual JVM mode". A native image process uses LoadLibraryA to dynamically load HotSpot JVM.

This used to work in graalvm-community-openjdk-24.0.1+9.1 on Linux, Macs, Windows.

It is broken on Windows since graalvm-community-openjdk-25+15.1 (it still works on Linux and Macs).

Analysis has revealed

• the problem is in the linking process.
• there is too many /EXPORTS in GraalVM 25 version!

E.g. the cause is known. However it is not clear what commit has changed the behavior and how to mitigate that.

Using the latest version of GraalVM can resolve many issues.

• I tried with the latest version of GraalVM.

GraalVM Version

The behavior is on Windows since graalvm-community-openjdk-25+15.1. Previous version graalvm-community-openjdk-24.0.1+9.1 used to work fine.

Operating System and Version

Windows 11

Troubleshooting Confirmation

• I tried the suggestions in the troubleshooting guide.

Run Command

I have prepared a sample project pull request demonstrating the failure. Get the source, checkout UseNio branch and then:

$ mvn -Pnative package
$  ./target/LaunchJdkViaJni.exe org/apidesign/demo/launchjdkviajni/DumpDisk

we seem to be green on old GraalVM versions, but red on GraalVM 25:

Expected Behavior

• the sample project works as it used to work on GraalVM for JDK21 and GraalVM for JDK24
• on a deeper level we have to convince the linker
• to link the JNI method to the dynamically loaded nio.dll and not to global symbol from native image

Actual Behavior

$ mvn -Pnative package
$  ./target/LaunchJdkViaJni.exe org/apidesign/demo/launchjdkviajni/DumpDisk

we seem to be green on old GraalVM versions, but red on GraalVM 25:

Steps to Reproduce

I have prepared a sample project pull request demonstrating the failure. Get the source, checkout UseNio branch and then:

$ export JAVA_HOME=/path/to/graalvm
$ mvn -Pnative package
$  ./target/LaunchJdkViaJni.exe org/apidesign/demo/launchjdkviajni/DumpDisk

this command succeeds with graalvm-community-openjdk-24.0.1+9.1 it is broken on Windows since graalvm-community-openjdk-25+15.1

Additional Context

No response

Run-Time Log Output and Error Messages

No response

[JaroslavTulach]

the cause is known. However it is not clear what commit has changed the behavior and how to mitigate that.

• I am trying to "bisect" the daily builds.
• however the oldest GraalVM25 build I can find is https://github.com/graalvm/graalvm-ce-dev-builds/releases/download/25.0.0-dev-20250330_0033/graalvm-community-java25-windows-amd64-dev.zip and that one already fails
• we know that graalvm-community-openjdk-24.0.1+9.1 is fine
• but I don't have access to any builds between 24.0.1+9.1 and 20250330...
• CCing @ansalond - Danilo, do you know if any such daily builds are available outside of Oracle?
• if such a builds are only available internally - could someone with access try to "bisect" them for me?

[JaroslavTulach]

With the help of link.exe I can see the problem. The LaunchJdkViaJni.exe generated by the sample project's PR 4 has just a few exported symbols when compiled by GraalVM 24:

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64\link.exe" /DUMP .\LaunchJdkViaJni.exe /exports

Dump of file .\LaunchJdkViaJni.exe

File Type: EXECUTABLE IMAGE

  Section contains the following exports for LaunchJdkViaJni.exe

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
          30 number of functions
          30 number of names

    ordinal hint RVA      name

          1    0 00039880 IsolateEnterStub__CEntryPointNativeFunctions__attachThread__LWiahz8fydJWgxqffuaEC2
          2    1 00039A60 IsolateEnterStub__CEntryPointNativeFunctions__createIsolate__aVxZJEvxfd8FslyQXMlHNI
          3    2 00039C70 IsolateEnterStub__CEntryPointNativeFunctions__detachAllThreadsAndTearDownIsolate__OPBluFOA7k6a9G1cqb6TTL
          4    3 00039ED0 IsolateEnterStub__CEntryPointNativeFunctions__detachThread__vZogK8TBGAIeNIWWaZu2QH
          5    4 0003A220 IsolateEnterStub__CEntryPointNativeFunctions__getCurrentThread__p19YkdKU3I3cgUmQuiiTd0
          6    5 0003A410 IsolateEnterStub__CEntryPointNativeFunctions__getIsolate__4JMPcmfHydBLuvj7ff2do8
          7    6 0003A440 IsolateEnterStub__CEntryPointNativeFunctions__tearDownIsolate__I3DVyDKs6z4vL79kJC9BEE
          8    7 00063890 IsolateEnterStub__JNIInvocationInterface_0024Exports__JNI__CreateJavaVM__zfv8XhXAFhERNPUoh38uvF
          9    8 00063C00 IsolateEnterStub__JNIInvocationInterface_0024Exports__JNI__GetCreatedJavaVMs__jTTCq2UmbC48XDHPdLhle5
         10    9 00063E20 IsolateEnterStub__JNIInvocationInterface_0024Exports__JNI__GetDefaultJavaVMInitArgs__8P9gtUmW2O2BqcAmkyOH99
         11    A 000654E0 IsolateEnterStub__JavaMainWrapper__run__cXbfAhOWcF90761nQYco7L
         12    B 00063890 JNI_CreateJavaVM
         13    C 00063C00 JNI_GetCreatedJavaVMs
         14    D 00063E20 JNI_GetDefaultJavaVMInitArgs
         15    E 00001000 __svm_code_section
         16    F 005BD850 __svm_version_info
         17   10 005BD820 __svm_vm_java_version
         18   11 005BD9E8 __svm_vm_target_ccompiler
         19   12 005BD9A0 __svm_vm_target_libc
         20   13 005BD880 __svm_vm_target_libraries
         21   14 005BDB20 __svm_vm_target_platform
         22   15 005BDBE8 __svm_vm_target_staticlibraries
         23   16 00039880 graal_attach_thread
         24   17 00039A60 graal_create_isolate
         25   18 00039C70 graal_detach_all_threads_and_tear_down_isolate
         26   19 00039ED0 graal_detach_thread
         27   1A 0003A220 graal_get_current_thread
         28   1B 0003A410 graal_get_isolate
         29   1C 0003A440 graal_tear_down_isolate
         30   1D 000654E0 main

  Summary

        3000 .data
       1B000 .pdata
       1A000 .rdata
        A000 .reloc
        5000 .rodata
      7D0000 .svm_hea
      5A2000 .text

While when I compile the executable with GraalVM 25, it contains 278 exported symbols including Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0!

E.g. we know where the problem is. The remaining question: how does one tell native-image.cmd in GraalVM 25 to don't export these symbols?

[JaroslavTulach]

Now I know where the exported symbol is coming from. GraalVM24 nio.lib does not export Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0 - the line:

/EXPORT:Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0

is missing in following dump output (as generated by GraalVM 25):

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64\link.exe" /DUMP C:\graalvm-community-openjdk-25+15.1\lib\static\windows-amd64\nio.lib /all | findstr FindFirstFile0
     FF14 Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
        4 Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
   /EXPORT:Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
         COMDAT; sym= Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
         COMDAT; sym= $unwind$Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
         COMDAT; sym= $pdata$Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
 00000008  ADDR32NB                   00000000       199  $unwind$Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
0E8 00000000 SECT17 notype ()    External     | Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
199 00000000 SECT59 notype       Static       | $unwind$Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0
19C 00000000 SECT5A notype       Static       | $pdata$Java_sun_nio_fs_WindowsNativeDispatcher_FindFirstFile0

now it is clear that "bisecting graalvm" will not help anything as the change is somewhere in the way "labs JDK" generates its static .lib files.

[JaroslavTulach]

• I thought the problem could be in labsJDK used to build GraalVM
• but the same problem happens on Mandrel 24 vs. 25 and Mandrel isn't using labsJDK
• thus the problem must be caused by some change in OpenJDK

[JaroslavTulach]

• Solution found: Invoke java.nio.file.Files in both JVMs JaroslavTulach/LaunchJdkViaJni#4 (comment)
• Let this issue be closed!

[JaroslavTulach]

@peter-hofer, at the end the solution was even more complicated: here is the diff

• there is the enso.def - listing some exports important for shims - are they all?
• right now I have enso.exp and enso.lib in our repository - I don't like it so:
• I'd like to generate them - but how do I get access to the right lib.exe? How can I access the info about tool chain?
• the biggest problems were with shims
• they need enso.lib in temporary directory
• I found a very hacky way to find all SVM* directories in our Feature, but I don't like it either.

However I am not completely sure how the ideal solution should look like? Should the windows liker generate enso.def itself and use it internally? That would allow me to remove most of these changes...

[olpaw]

However I am not completely sure how the ideal solution should look like? Should the windows liker generate enso.def itself and use it internally? That would allow me to remove most of these changes...

@pejovica would be most qualified to comment on this. He implemented the shims solution for NI to allow us to use the dynamic lib version of awt.