As mentioned previously, SST supports both remote procedure call and remote object invocation computing models. The fundamental difference between these two computing models lies in whether parameters and return values used in remote method invocation are passed by-value or by-reference. This infrastructure behavior is often referred to as the selected message passing mechanism, and is determined by the kind of marshaler specified for the invocation handler.

Many client-server applications do not require pass by-reference semantics, as message parameters and values are relatively simple and do not have relevant identity. In such cases, pass by-value is sufficient. Examples of this are typical data-oriented servers such as databases and HTTP servers.

Depending on the application, however, pass-by-value may result in large amounts of data being passed around, as entire object graphs rooted in the request arguments are marshaled and sent. Passing by-reference is generally more efficient in terms of quantity of bytes transmitted, but may require more remote message sends due to the cross-space references. On the other hand, passing values means that during computation all arguments are local, and consequently the number of remote messages may be significantly reduced.

Performance considerations aside, references have some distinct - though possibly more subtle - advantages. The most important of these is that they maintain object identity. This is extremely useful, if not essential, for some applications.

In addition, the use of references facilitiates location transparency. Regardless of whether a variable (foo) contains a local object or a remote reference, the code foo doSomething will execute. Without remote references you must explicitly code for remote objects. An illustration of this can be seen by comparing the sendPing:with: methods in the ping-pong example.

There are disadvantages to the use of remote references that belie their seeming simplicity. Naive use of pass-by-reference can result in the proliferation of inter-space dependencies, resulting in unintended remote messages and distributed garbage. SST does provide a distributed garbage collector, but collecting garbage is a performance hit.

It's also possible that execution semantics can be corrupted using remote references. For example, invoking value: on a remote reference to a block that performs an out-of-scope return will not have the intended effect.

Overall, which message passing mechanism is best depends on the demands of your application and its computing characteristics.