aws / aws/aws-sdk-java-v2

Graal Native Image reports large numbers of objects from software.amazon.awssdk.services.*

Aperta
#3,525 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

feature-request graalvm p3
Lingua principale
Java
Stelle
2.6k
Fork
1k
Merge medio
2g 9h
PR unite (30g)
51

Descrizione

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

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia riproducendo i conteggi segnalati di oggetti e pacchetti di native-image con AWS Java SDK 2.18.6, GraalVM 17.0.4 e le dipendenze Gradle, Quarkus e AWS elencate. Esamina perché i pacchetti dei modelli di SSM, DynamoDB ed EventBridge sono raggiungibili e determina se sia fattibile un’ottimizzazione a livello di libreria. Il lavoro è considerato completato quando la causa è stata identificata e viene definita o implementata una riduzione misurabile nel binario nativo o nel report di build.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
java
Ambito
cloud
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.