Description
openedon Mar 25, 2024
Describe the bug
#39615 triggered a bit of an analysis since the ImageMetricsITCase.verifyImageMetrics test was failing. As it turns out that PR wasn't the culprit, but just so happens to push the reflective types value over the edge. This isn't very satisfying as it would be better to have actual failures when regressions happen.
Anyway, since commit 612d816 which introduced per GraalVM version metric thresholds (done on Nov 28, 2023) to commit e7f2a1e (done on Mar 25, 2024) we see an image size increase from 80.31MB to 81.05MB even though the same Mandrel version - Mandrel-23.1.2.0-Final - is being used for the same application integration-tests/jpa-postrgesql. It doesn't seem a lot, but this is a death by a thousand cuts problem.
Looking at some properties we see a couple of changes in reachability data and resulting code area and image heap sizes:
Before
Commit: 612d816
38.36MB (47.77%) for code area: 63,380 compilation units
41.55MB (51.73%) for image heap: 458,866 objects and 56 resources
407.17kB ( 0.50%) for other data
80.31MB in total
Build output json:
{"resource_usage":{"memory":{"system_total":67167305728,"peak_rss_bytes":5453029376},"garbage_collection":{"count":122,"total_secs":8.476,"max_heap":28445245440},"cpu":{"load":8.029142189822352,"parallelism":12,"total_cores":12},"total_secs":112.375389819},"image_details":{"code_area":{"bytes":40228608,"compilation_units":63380},"total_bytes":84210608,"image_heap":{"bytes":43565056,"objects":{"count":458866},"resources":{"bytes":162584,"count":56}}},"general_info":{"c_compiler":"gcc (redhat, x86_64, 13.2.1)","name":"quarkus-integration-test-jpa-postgresql-999-SNAPSHOT-runner","java_version":"21.0.2+13-LTS","garbage_collector":"Serial GC","graal_compiler":{"march":"x86-64-v3","optimization_level":"2"},"vendor_version":"Mandrel-23.1.2.0-Final","graalvm_version":"Mandrel-23.1.2.0-Final"},"analysis_results":{"types":{"total":22118,"reflection":6156,"jni":61,"reachable":19660},"methods":{"foreign_downcalls":-1,"total":178490,"reflection":4577,"jni":55,"reachable":97675},"classes":{"total":22118,"reflection":6156,"jni":61,"reachable":19660},"fields":{"total":44430,"reflection":195,"jni":61,"reachable":27074}}}
After
Commit: e7f2a1e
38.93MB (48.03%) for code area: 63,931 compilation units
41.72MB (51.48%) for image heap: 461,111 objects and 59 resources
405.73kB ( 0.49%) for other data
81.05MB in total
Build output json:
{"resource_usage":{"memory":{"system_total":67167305728,"peak_rss_bytes":8445833216},"garbage_collection":{"count":48,"total_secs":6.66,"max_heap":28445245440},"cpu":{"load":8.068393069601427,"parallelism":12,"total_cores":12},"total_secs":106.842836721},"image_details":{"code_area":{"bytes":40822208,"compilation_units":63944},"total_bytes":84988848,"image_heap":{"bytes":43749376,"objects":{"count":461305},"resources":{"bytes":170272,"count":59}}},"general_info":{"c_compiler":"gcc (redhat, x86_64, 13.2.1)","name":"quarkus-integration-test-jpa-postgresql-999-SNAPSHOT-runner","java_version":"21.0.2+13-LTS","garbage_collector":"Serial GC","graal_compiler":{"march":"x86-64-v3","optimization_level":"2"},"vendor_version":"Mandrel-23.1.2.0-Final","graalvm_version":"Mandrel-23.1.2.0-Final"},"analysis_results":{"types":{"total":22308,"reflection":6228,"jni":61,"reachable":19837},"methods":{"foreign_downcalls":-1,"total":179645,"reflection":4708,"jni":55,"reachable":98501},"classes":{"total":22308,"reflection":6228,"jni":61,"reachable":19837},"fields":{"total":44929,"reflection":195,"jni":61,"reachable":27358}}}
So in this case we went from 6156 to 6228 reflectively reachable types and from 63380 to 63944 compilation units. More analysis needed to find the worst offenders.
How to Reproduce?
Build mentioned quarkus revisions and then the integration-tests/jpa-postrgesql app natively on Linux with Mandrel-23.1.2.0-Final.
Output of uname -a or ver
Linux x86_64