Applications which require object identity to be maintained across Smalltalk images or whose objects are too large to transfer by value should use by-reference marshaling. By-reference marshaling is based on a dynamic replacement of objects with remote references. Remote references are globally unique identifiers of a local object. These remote references are managed by object spaces as described in Object spaces.

Message marshalers which support by-reference configurations (both of the standard SST marshalers do so) expose standard ones to you through a class method specified below:

Again, the configuration returned by this method should be installed on an invocation handler configuration where it is used to build the relevant structures when the handler is started. Note that in the case of by-reference marshaling, the invocation handler's space must be configured to handle remote references.

By-reference marshaling is more complicated than by-value marshaling in that not all objects can or should be passed as references. For example, objects such as SmallIntegers are "immediate" values and only exist as values. Others are immutable in the sense that the system provides no (or little) API which changes the value of the object, for example, instances of Float. Still other objects, such as Strings and Points, while technically mutable, are immutable in common usage.

SST defines a number of classes as immutable by defining a method sstIsImmutable to return true. You are free to define such methods on their classes but should keep in mind the issues raised in the by-value marshaling section. Note also that defining this method changes the marshaling for all instances of the class in which the method is defined as well as all of its subclasses (assuming they do not also override the method). Finer-grained control of by-value/reference marshaling can be had using the marshaling wrappers (see Marshaling wrappers).

All objects which are mutable are passed by reference. SST can define a default remote reference for an object but allows users to specify their own by overriding the method sstExportObjectIn: in the desired classes. This message is sent to any mutable object found by the marshaler. The result is used as the exported value which is embedded in the message. The single argument is the object space related to the marshaler and in which the receiver is exported. Note that it is your responsibility to ensure that the appropriate exporting operations are carried out in this method. The default (Object) behavior of this method is shown below:

A simple example of varying this is given below. By overriding sstExportObjectIn: in Process you specify that reference to processes be exported as instances of a special "remote" process class (SstRemoteProcess), which is a remote reference having caching capabilities and other optimizations.