Branch: refs/heads/main
Revision: c2e3d3797ea8cfbe90a5d65e0103ebcaab589635
Author: dlongnecke-cray
Link: dlopen: Clean up RT's private broadcast API and adjust gasnet by dlongnecke-cray · Pull Request #28902 · chapel-lang/chapel · GitHub
Log Message:
dlopen: Clean up RT's private broadcast API and adjust gasnet (#28902)
This PR adjusts the runtime's private broadcast API in order to better
facilitate dynamic loading.
Prior to this effort, the runtime would build what I call a "unified
broadcast table" at execution-time. This table is an address table that
contains the contents of the broadcast table from the "root Chapel
program" combined with some additional RT-exclusive symbol addresses
tacked on at the end.
The problem with this approach is that it is not conducive to dynamic
loading because the runtime only reasons about a single table. While it
might be possible to dynamically resize the table as needed to support
multiple Chapel programs, I thought it might be simpler if we just
remove the dynamic address table entirely, and let the runtime fetch the
address table from the specific Chapel program that it needs (or its own
address table).
While I feel confident this "separate table" approach works with gasnet,
I haven't spent the time to investigate how it will work with the ofi
comm layer. Because I'm not adjusting ofi in this release, I'm still
keeping the old "unified broadcast table" around for now. I've renamed
it to chpl_rt_unified_private_broadcast_table.
In general, I've refactored the symbols used in the private broadcast
API and implementation to have a more consistent and legible naming
scheme (continuing the theme of clarity over brevity).
The runtime used to name its private broadcasting functions as
...broadcast_private. I've adjusted this to be ...private_broadcast
so that the terminology is consistent everywhere.
This PR introduces another runtime shim into
ChapelRuntimeInterface.chpl which the compiler will invoke whenever it
needs to broadcast a symbol's value to all locales.
Future work could improve the implementation's robustness w.r.t.
potential overflows or take advantage of new routines provided by the
GASNet-EX API, for example gex_Coll_BroadcastNB as suggested by
@bonachea.
TESTING
-
standard -
COMM=gasnet -
COMM=gasnet,COMPILER=gnu - Build with
COMM=ofi - Build with
gasnet-asan, runfastAndIncremental.chpl
Reviewed by @benharsh, @bonachea. Thanks both!
Diff:
M compiler/codegen/cg-expr.cpp
M modules/internal/ChapelRuntimeInterface.chpl
M runtime/include/chpl-comm-diags.h
M runtime/include/chpl-comm-internal.h
M runtime/include/chpl-comm.h
M runtime/include/chpl-prginfo-program-only-decls.h
M runtime/include/chplcgfns.h
M runtime/src/chpl-comm-diags.c
M runtime/src/chpl-comm.c
M runtime/src/chpl-gpu-diags.c
M runtime/src/chplmemtrack.c
M runtime/src/comm/gasnet/comm-gasnet-ex.c
M runtime/src/comm/none/comm-none.c
M runtime/src/comm/ofi/comm-ofi.c
M runtime/src/comm/ugni/comm-ugni.c
https://github.com/chapel-lang/chapel/pull/28902.diff