Add gc_safe option to @mpicall and @mpichk macros

[giordano]

Note: the diff is quite large because the file with the generated API changed a lot. I split the changes into different logically consistent commits, for easier review. I also got the bot to always generate from now on the file with a stable sorting, instead of relying on the order of the functions in the upstream header file (which isn't really stable).

@vchuravy for the time being I marked only MPI_Wait and MPI_Allreduce, do we need to support more functions?

Fix #954.

[giordano]

@vchuravy for the time being I marked only MPI_Wait and MPI_Allreduce, do we need to support more functions?

The bot suggests

gc_safe = (
    # request completion and probes
    :MPI_Wait, :MPI_Waitall, :MPI_Waitany, :MPI_Waitsome,
    :MPI_Probe, :MPI_Mprobe, :MPI_Mrecv,
    # blocking point-to-point
    :MPI_Send, :MPI_Ssend, :MPI_Recv, :MPI_Sendrecv, :MPI_Sendrecv_replace,
    # blocking collectives
    :MPI_Barrier, :MPI_Bcast,
    :MPI_Gather, :MPI_Gatherv, :MPI_Scatter, :MPI_Scatterv,
    :MPI_Allgather, :MPI_Allgatherv, :MPI_Alltoall, :MPI_Alltoallv, :MPI_Alltoallw,
    :MPI_Reduce, :MPI_Allreduce, :MPI_Reduce_scatter, :MPI_Reduce_scatter_block,
    :MPI_Scan, :MPI_Exscan,
    # blocking neighborhood collectives
    :MPI_Neighbor_allgather, :MPI_Neighbor_allgatherv,
    :MPI_Neighbor_alltoall, :MPI_Neighbor_alltoallv, :MPI_Neighbor_alltoallw,
)

[vchuravy]

The only thing I am worried about is the MPI_Probe since they should be very fast.

[giordano]

The bot really insisted that probes are fine

• MPI_Mrecv — the one I nearly cut. After MPI_Mprobe the message is matched, so it "should" be a bounded copy. But matching only guarantees the envelope arrived: for a large rendezvous message the payload transfer happens inside MPI_Mrecv, and it needs the sender's MPI library to answer the clear-to-send. MPI implementations don't guarantee asynchronous progress — if the sender rank is off in compute code, that answer waits until it re-enters MPI. Unbounded tail. Keep.

[...]

MPI_Probe is one of the strongest candidates on the list — it sits at the opposite end of the spectrum from MPI_Mrecv.

On the "worth it" test: its entire job is to block until a matching message envelope arrives, i.e. until a peer rank posts the corresponding send. That's a pure peer-progress wait with no local-work bound at all — there isn't even a fast typical case to speak of, since code reaches for MPI_Probe precisely when it doesn't know when (or how big) the message will be. A rank sitting in MPI_Probe waiting for a slow peer while holding up GC on every other thread is exactly the motivating pathology.

On the safety test: it's about as inert as an MPI call gets — it doesn't touch user buffers at all, writes only a bits-type MPI_Status, receives nothing, and has no callback path (unlike MPI_Wait, it doesn't complete other pending operations' reduction ops; it only inspects the matching queue and drives progress internally).

So: keep, with confidence. Same verdict for MPI_Mprobe, which is the same wait with a matched-message handle as output.

In any case I don't have a need for marking these functions as gc-safe, so I dropped them.

[giordano]

@vchuravy this was entirely the bot's initiative, I'm not quite sure whether it's true that multi-threaded applications need

MPI.Init(; threadlevel=:multiple)

to make the GC run concurrently with the MPI functions. I'm happy to remove this if it's garbage (pun intended).

[vchuravy]

Oh that is fun... it is an interesting question what happens when we run MPI_*_free from a finalizer...