Best Practices to help the static analysis when generating native images?

[Jiehong]

Hello,

I started a discussion at remkop/picocli#1909, because picocli is a huge single source file, and so a single module, and I wanted to better understand if this has an impact on the generated native image size by graalvm.

Here are a few questions I have:

• Is having the code in different files helpful to reduce native image size?
• Is using annotations (converted at compile time to generated code) any different that writing that code by hand in the first place to reduce native image size?
• Is splitting code in multiple java modules helpful in reducing native image size?
• etc.

In the end, I'm wondering if there are a set of best practices that one could follow to help the static analysis of graalvm to generated smaller native image sizes.

[cstancu]

Hi @Jiehong, how the code is organized shouldn't make much difference on analysis/compilation performance. From the point of view of the analysis what matters is if it can prove that some execution paths can never be taken, e.g., if it can prove that a variable x always has type A then the else branch of a if(x instanceof A) can be eliminated. The analysis consumes the code one method at a time, regardless of how the code is divided in files, but organizing the code in type hierarchies may give more type hints and enable more aggressive optimizations. Generated code doesn't hurt the analysis as long as the generated code is not unnecessarily large when compared to the manually written equivalent.

[Jiehong]

thanks