-
-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency on .class and .tasty files causes footprint bloat for GraalVM NativeImage #642
Comments
I don't much about building GraalVM native images. Can you find a way to exclude the |
The tasty lookup can be disabled at runtime by calling this API supportScala3Classes(support: Boolean): Unit |
Yes, that's easy enough to do, but then you get run-time errors because they aren't there. Native Image depends on knowing about reflective accesses at build time, the usual way of determining that is to run your app in normal JVM mode with a tracing agent that intercepts all the reflective calls and writes them to a config file for use when building the image.
Presumably that will break Scala3 support, which I'm using? I've done some more digging, I'm also using |
Frankly if you want tiny images then you should probably consider not using Scala. Scala is not tailored for the tiny image use case. |
I realise that, but when you have hard size limits on the resulting image, pulling in As I said I'd hesitate to call this a bug but it's taken me a while to figure out why those files were being included in the Native Image, in the pure-Java case |
Both
.class
and.tasty
files are read at run time, e.g..class file access stack trace
.tasty file access stack trace
This isn't an issue for normal JVM usage, but if the application is built with GraalVM Native Image it results in both the
.class
and.tasty
files being included in the resulting executable, leading to increased footprint.With the correct NativeImage reflection configuration the image does work so I'd hesitate to call this an outright bug, but the requirement to access both
.class
and.tasty
files at runtime is an issue if Native Image size is a concern.There may be nothing that can be done about the need to include
.tasty
files for runtime access. I may be wrong, but from a cursory look it appears thatcom.thoughtworks.paranamer
is being used to replicate functionality such as reading parameter names that can be done directly?The text was updated successfully, but these errors were encountered: