Example of how to use the plugin to produce and consume a PGO file

[lestephane]

Is your feature request related to a problem? Please describe. I found this page https://www.graalvm.org/22.0/reference-manual/native-image/PGO/

Describe the solution you'd like I'd like to understand how to produce and consume the PGO file describe in that page using the gradle plugin.

[lazar-mitrovic]

As per Gradle plugin docs you should be able to add arguments to the native-image invocation. In your use-case that should be something like:

graalvmNative {
    binaries {
        main {
        // ...
        buildArgs.add('--pgo-instrument') // for building an instrumented native image
        // or
        buildArgs.add('--pgo=<path_to_profile>') // for building  the second native image
        // ..
        }
    }
}

[lestephane]

I don't get it. The binaries section only allows me to have a main and test binary. The main binary will get the extra buildArgs.add('--pgo=<path_to_profile>'). That much is clear.

What I'm wondering is where the buildArgs.add('--pgo-instrument') goes. Because it is related to a third binary (pgo, instrument) which runs as a simple program with a main method, and tries to exercise the same code path as the main binary, but is distinct from it in my view.

There is no concept of a third pgo / instrument binary modelled by the plugin. I could add switch statements in the .kts file to change the main class on the fly and the pgo argument on the fly, but that's not what I would call ergonomic. The main native image call depends on the pgo / instrument call having run first, so that the pgo file is present. All of these dependencies could be modelled in gradle out of the box potentially.

I was asking for a full example, not a quote of the reference doc. Anyone can do that. By contrast, noone seems to know how to actually use this pgo feature. I have only found two matches for pgo-instrument on github, both of them commented out, in a maven pom.xml. There's a gap here.

[lazar-mitrovic]

Oh I see, sorry for closing this issue so quickly.

If I understand correctly there are several issues here:

1. Registering non-test binaries other than main. We have registerTestBinary but this wouldn't fit the PGO use-case as it explicitly specifies main class (if I'm correct @melix).
2. First party support for PGO in native-build-tools. This is something that we should do, but we still haven't got around to (we are still in 0.9.x).

As of now AFAIK you can invoke PGO by making a shell script, or by crafting custom JavaExec task, but I don't believe that we have some nice build tool integration for this.

[lestephane]

Thanks for re-opening. If I come up with a workaround worth sharing in the meantime, I'll share what I can.