Graal Native Image reports large numbers of objects from software.amazon.awssdk.services.*
- Dominant language
- Java
- Stars
- 2.6k
- Forks
- 1k
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 51
Description
### Describe the feature
We have been using Graalvm to build native image lambdas for almost a year now and one thing that has been constant in this time is the large number of objects being generated by software.amazon.awssdk.services.*.
A not untypical and possibly conservative build report would like like this:
```
------------------------------------------------------------------------------------------------------------------------
Top 10 packages in code area: Top 10 object types in image heap:
7.12MB software.amazon.awssdk.services.ssm.model 36.83MB byte[] for embedded resources
3.15MB software.amazon.awssdk.services.dynamodb.model 9.75MB byte[] for code metadata
2.00MB software.amazon.awssdk.services.eventbridge.model 7.65MB java.lang.Class
1.98MB com.oracle.svm.core.code 7.56MB byte[] for java.lang.String
1.66MB sun.security.ssl 6.41MB byte[] for reflection metadata
1.38MB com.oracle.svm.core.reflect 4.80MB java.lang.String
1.01MB java.util 3.89MB byte[] for general heap data
812.63KB software.amazon.awssdk.services.dynamodb 3.80MB c.oracle.svm.core.reflect.SubstrateMethodAccessor
723.52KB jdk.internal.net.http 2.61MB com.oracle.svm.core.hub.DynamicHubCompanion
718.29KB software.amazon.awssdk.services.ssm 1.92MB java.lang.Object[]
23.35MB for 534 more packages 11.95MB for 14241 more object types
------------------------------------------------------------------------------------------------------------------------
22.4s (7.8% of total time) in 66 GCs | Peak RSS: 6.15GB | CPU load: 3.32
------------------------------------------------------------------------------------------------------------------------
```
We do use ssm/dynamodb and eventbridge but the build stats are continually dominated by these excessive aws objects.
Why is all of the model reachable, are there any plans to improve this over time…
### Use Case
Lambda binary size is one of the important factors in cold start times. Whilst the binary size can be reduced using UPX, this has the effect of making the cold start time longer. Ideally, the objects generated at build time should be optimised. You will note that I have not had to hide any of our internal packages from the list above. We have tried to minimise our impact on the binary size and optimise cold start as much as we can.
It _feels_ like the aws objects are excessive, but not knowing the codebase well I am unable to understand if this is the most efficient it can be made or not.
If an optimisation can be made in the libraries so that they do not generate large numbers of objects this will decrease the ultimate binary size and should also decrease the cold start times too. Win:win
### Proposed Solution
I have no idea how to resolve this, merely making a feature request for the team to investigate if and/or why so many obects are created at build time and if this be optimised somehow.
### Other Information
We use gradle 7.5.1 to perform our build:
```
------------------------------------------------------------
Gradle 7.5.1
------------------------------------------------------------
Build time: 2022-08-05 21:17:56 UTC
Revision: d1daa0cbf1a0103000b71484e1dbfe096e095918
Kotlin: 1.6.21
Groovy: 3.0.10
Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM: 17.0.4 (GraalVM Community 17.0.4+8-jvmci-22.2-b06)
OS: Linux 4.14.291-218.527.amzn2.x86_64 amd64
```
All our code is pojo java with no java features beyond java 11. We use quarkus dependencies for native build optimisations:
```
implementation(enforcedPlatform('io.quarkus:quarkus-bom:2.13.3.Final'))
implementation(platform('software.amazon.awssdk:bom:2.18.6'))
implementation(platform('io.quarkus.platform:quarkus-amazon-services-bom:2.13.3.Final'))
```
### Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
### AWS Java SDK version used
2.18.6
### JDK version used
17.0.4 (GraalVM Community 17.0.4+8-jvmci-22.2-b06)
### Operating System and version
Linux 4.14.291-218.527.amzn2.x86_64 amd64
Contributor guide
Assessment
This issue has not been assessed yet.