upc++ needs to gracefully handle gasnet limit on explicit events

[Steven Hofmeyr]

It is easy to generate enough outstanding upc++ operations that the event/handle limit in gasnet is exceed (it's 65535). Here is sample code that does it (if num_iters is large enough):

 upcxx::future<> f_chain = upcxx::make_future();
    for (int64_t i = 0; i < num_iters; i++) {
        char tmp[data_size];
        uint64_t key = distr(gen);
        auto f = insert_data(key, tmp, data_size);
        if (async) f_chain = upcxx::when_all(f_chain, f);
        else f.wait();
    }
    if (async) f_chain.wait();

Here's Dan's comment:

It may be possible to raise the handle limit in EX, but it's probably not a good idea for the >UPC++ runtime to let the number of outstanding operations grow without bound (for cache >performance reasons). The UPC++ runtime could easily exert backpressure at some point >(eg spinning on internal progress to reap handles) to avoid generating too many >simultaneous communication handles.

[Dan Bonachea]

With today's advance of collaborator-snapshot, the 65k limit on simultaneous explicit-handle events has been removed in GASNet-EX. GEX explicit-handle events are now only limited by the size of the malloc heap (on most conduits each consumes one cache line of GASNet internal storage while the event is "live"), so effectively unlimited.

Consequently the original program should now operate correctly, at least as far as GASNet is concerned.

That being said, the program will still exhibit less asynchrony than the programmer expected and execute sub-optimally as a result, due to lack of calls to upcxx::progress() in the injection loop. This programmability issue has been moved to guide issue 24