Clarify Serializable wrt raw pointers and function pointers/objects

[Dan Bonachea]

Our current definition for Serializable is:

C++ TriviallyCopyable or by overriding the global upcxx::serialize function for their special types

TriviallyCopyable includes all scalar types, which notably includes raw (local) pointers, and pointers to functions.

However both forms of raw pointer are not automatically meaningful in a distributed-memory environment. There are several related problems here:

1. We need to clarify that implementations are required to support trivial serialization (and portable meaning) of (scalar) pointers to functions - this entails non-trivial implementation effort on platforms with position-independent executables and address space randomization, or in the presence of pointers to functions in dynamically-loaded libraries. We may want to leave the latter case as implementation-defined, since a portable implementation for dynamic loading may be impossible.

2. Other raw pointers (eg raw C++ pointers to non-function objects) are Serializable but not meaningful to other ranks (not even guaranteed for the special case of a downcast pointer to a shared object with affinity to local_team() and a peer on the same team). This means any type serialized (via any method) that involves a trivial copy of such a raw pointer potentially renders the entire resulting object as meaningless (to another rank). There's no other possible/guaranteeable semantics here, but our normative spec doesn't explicitly state this restriction anywhere.

3. As a further clarification to .1 and .2, a FunctionObject which is a real user-defined class containing a field that is a pointer to a function might satisfy the definition of TriviallyCopyable (and hence Serializable), but it is (probably?) not guaranteed to be meaningful to other ranks. Specifically, I suspect our magic for localizing a pointer-to-function into the local code segment won't work if that pointer-to-function is buried as a field in an opaque user-defined object (and called indirectly through the user-provided implementation of FunctionObject::operator())

[Paul Hargrove]

An additional item from the 2017.09.15 call:

We need some language to define which function pointers receive special treatment.
We seemed to agree on the call that we need to say that the implementation is required to perform the translation for the functions in the upc++ code (but need proper terminology).
We would then say that treatment of other libraries (STL, libc, libm, libblas, etc.) is implementation-dependent.

[Dan Bonachea]

Also from the 2017.09.15 call:

In addition to C++ pointers to (non-function) data, there are other TriviallyCopyable values representing local resources that are also not meaningful to remote ranks - UNIX file descriptors being one obvious example.

[Dan Bonachea]

This issue was triaged at the 2018-06-13 Pagoda meeting and assigned a new milestone/priority.

[Amir Kamil]

Merged in d57cd44.