[GR-38835] native-image performance regression when using debug-info generation

[olpaw]

Merging of #4505 introduced a native-image performance regression when images are built with debug-info. Using -g should not have an affect on the performance of the image that gets built.

[adinn]

@olpaw Hi Paul. Can you just clarify a few things here.

1. I am not 100% clear sure I believe you are saying that the problem here is not that enabling full infopoints implies longer build times, rather that it is causing a slow-down in execution time for the generated mage. Is that correct?
2. Can you give any indication of how much much of a slowdown you were able to measure (also, if you can, how that varied according to what the test app was doing)
3. Do you know why enabling full infopoints causes this slowdown?

I ask because I think it is a very important goal to have full debuginfo, based on full infopoints, as the default when generating an image for deployment. Given that this change disables full infopoints for optimization levels O1 and O2 (O2 being the default) it prejudices that goal.

The reason for pursuing that goal is that it makes it a lot easier to deal with the, hopefully very rare circumstance that an issue in the GraalVM Native chain manifests in a deployed app. It avoids the need to rebuild the app with full infopoint generation enforced in order to best be able to debug it; and it bypasses the possibility that the problem fails to manifest in the rebuilt version. I'd really like to recommend Mandrel users to configure final builds of images for deployment so that they enforce full infopoint generation.

Obviously, it is important to know what the other side of the equation is here: i.e. what it might cost in deployment time performance if we were to recommend to a user to force full infopoints. So, any info you have on that cost would be helpful to know.

[olpaw]

@adinn enabling full infopoints cause performance regressions in the runtime of images. (Of course debug info generation time also increased due to debug location info generation but this is not the concern here.)

@farquet provided me with the numbers:

He might be able to provide more pointer to the actual benchmarks results.

Full infopoints keep locals alive beyond the point they would otherwise be the end of their live-range. This has a negative impact on optimizations.

[adinn]

@olpaw Thanks for providing those figures. That's definitely a significant regression :-(

[farquet]

Benchmark numbers are public: https://graal.d3s.mff.cuni.cz/see/overview

You can browse individual performance regressions/speedups and it will tell you more about the JVM configuration, the absolute scores, candidate culprit commits, hardware info, etc