Open AlanBurlison opened 1 year ago
I don't much about building GraalVM native images. Can you find a way to exclude the .tasty
files when you build your on images?
The tasty lookup can be disabled at runtime by calling this API
supportScala3Classes(support: Boolean): Unit
Can you find a way to exclude the .tasty files when you build your on images?
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.
The tasty lookup can be disabled at runtime by calling this API
supportScala3Classes(...
Presumably that will break Scala3 support, which I'm using?
I've done some more digging, I'm also using com.github.pjfanning.scala3-reflection
and the associated compiler plugin, plus com.fasterxml.jackson.module.scala.ClassTagExtensions
. If I remove all those, from first look it appears that the access to the .class
& .tasty
files goes away and for my app at least, things still work - but as I'm not entirely clear how all the bits mesh together in the first place...
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 .class
and .tasty
files is significant.
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 .class
files aren't pulled in. If nothing else this info will help others trying to do the same thing.
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?