Open jerboaa opened 3 months ago
/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel,native-image)
Using the data gathered by the Mandrel CI weekly jobs (Testing Q main with Mandrel 23.1) I see that there was a change during the first week of the year that increased the total size by ~.5% and then there were two changes in early March that added another ~.2%, other than that the image gradually got bigger without any big jumps. ~Unfortunately_ the data seem not available after 24/1/24 so we need to have a look at that as well... I will see if I can gather any more data.~ Edit: I was using an older instance of the database...
Now if we go even further back in time things become more concerning/interesting.
The most important dates, i.e. the ones resulting in > 1% increase that don't seem to be fixed/reverted yet (accounting for major Mandrel changes like a new release) appear to be:
Timestamp | Total Size (MB) | Diff (%) | Mandrel Version |
---|---|---|---|
2022-09-30 07:04:52.175000+00:00 | 55.7676 | 1.05% | GraalVM 23.0.0-dev12610330 Java 17 Mandrel Distribution |
2022-11-05 06:42:19.689000+00:00 | 57.1857 | 1.82% | GraalVM 23.0.0-dev5e100c36 Java 17 Mandrel Distribution |
2022-12-17 05:48:59.896000+00:00 | 58.4155 | 1.69% | GraalVM 23.0.0-devfbb40f63 Java 17.0.6-beta+7-202212152331 Mandrel Distribution |
2023-02-22 04:33:28.541000+00:00 | 60.2696 | 1.71% | GraalVM 23.0.0-dev9f45be3e Java 17.0.7-beta+2-202302162331 Mandrel Distribution |
2023-02-24 04:56:00.564000+00:00 | 67.0470 | 11.25% | GraalVM 23.0.0-devac1c7c66 Java 17.0.7-beta+2-202302212331 Mandrel Distribution |
2023-11-10 01:53:32.393000+00:00 | 73.8674 | 3.82% | Mandrel-24.0.0-dev9115188f |
2023-11-23 13:19:24.017000+00:00 | 86.8830 | 17.13% | Mandrel-24.0.0-dev4887f282 |
2023-11-29 03:01:23.924000+00:00 | 88.1333 | 1.42% | Mandrel-24.0.0-devb3d20a4c |
The unstable period between mid June and late July in 2023 is also interesting.
Unfortunately for the period between 2023-07-28 and 2023-11-10 we don't have enough data from the nightly builds, but based on the weekly builds the main increase appears to have happened between 2023-07-28 and 2023-09-08:
Timestamp | Total Size (MB) | Diff (%) | Mandrel Version |
---|---|---|---|
2023-07-28 03:31:52.342000+00:00 | 71.1477 | 0.01% | Mandrel-23.1.0-dev8e6177a1 |
2023-09-08 17:56:09.202000+00:00 | 72.7101 | 2.20% | Mandrel-23.1.0.0-devc904cd96 |
Unfortunately, by just looking at these data it's not possible to tell in which case the increase comes from a Mandrel change or a Quarkus change, but at least they narrow down the search area.
Edit: Filtered the data to only keep nightly runs without overlapping Mandrel versions (for periods during which we were testing with two Mandrel versions).
The 2023-11-23 increase seems to be caused by https://github.com/quarkusio/quarkus/pull/35113 cc @marko-bekhta @yrodiere
The 2023-02-24 increase seems to be caused by https://github.com/quarkusio/quarkus/pull/31235 (which includes 83 commits and makes it hard to see if it's caused by the bump, or some specific change)
The 2023-11-29 increase seems to be caused by:
We now see an increase again for this tested app. We are now at an image size of 85721216
with latest 23.1
:
Multiple Failures (1 failure)
org.opentest4j.AssertionFailedError: Expected image_details.total_bytes to be within range [83036632 +- 3%] but was 85721216 ==> expected: <true> but was: <false>
at org.junit.jupiter.api.AssertAll.assertAll(AssertAll.java:80)
at org.junit.jupiter.api.AssertAll.assertAll(AssertAll.java:58)
at org.junit.jupiter.api.Assertions.assertAll(Assertions.java:3012)
See: https://github.com/graalvm/mandrel/actions/runs/8856285533/job/24322835033#step:12:658
Describe the bug
https://github.com/quarkusio/quarkus/pull/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 https://github.com/quarkusio/quarkus/commit/612d8169ebfeb1e082b499c910474934554e9a60 which introduced per GraalVM version metric thresholds (done on Nov 28, 2023) to commit https://github.com/quarkusio/quarkus/commit/e7f2a1ee4aff4c5efeba2d414fb696d0ac47f1f4 (done on Mar 25, 2024) we see an image size increase from
80.31MB
to81.05MB
even though the same Mandrel version -Mandrel-23.1.2.0-Final
- is being used for the same applicationintegration-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: https://github.com/quarkusio/quarkus/commit/612d8169ebfeb1e082b499c910474934554e9a60
Build output json:
After Commit: https://github.com/quarkusio/quarkus/commit/e7f2a1ee4aff4c5efeba2d414fb696d0ac47f1f4
Build output json:
So in this case we went from
6156
to6228
reflectively reachable types and from63380
to63944
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 withMandrel-23.1.2.0-Final
.Output of
uname -a
orver
Linux x86_64