| << Prev | - Up - | Next >> |
The current release has the following limitations and modifications with respect to the specifications of the distribution model and the failure model. A limitation is an operation that is specified but is not possible or has lower performance in the current release. A modification is an operation that is specified but behaves differently in the current release.
Most of the limitations and modifications listed here will be removed in future releases.
These reduce performance but do not affect language semantics. They can safely be ignored if performance is not an issue.
The following problems are related to the Remote module and virtual sites (see also Chapter 13 of ``System Modules'').
On some platforms (in particular, Solaris), the operating system in its default configuration does not support virtual sites efficiently (see also Chapter 13 of ``System Modules''). This is due to a system-wide limit on the number of shared memory pages. For Solaris, the default is six shared pages per process and 100 system-wide. Changing this limit requires rebooting the machine. Since at least two pages are needed for efficient communication, the default value results in poor performance if a site connects to more than three virtual sites.
The Mozart system does its best to reclaim shared memory identifiers, even upon process crashes, but it is still possible that some shared memory pages become unaccounted for and thus stay forever in the operating system. If this happens please use Unix utilities to get rid of them. On Solaris and Linux there are two, namely ipcs and ipcrm.
By default the code of functions, procedures, classes, and functors (but not objects) is always inserted in messages, even if the code is already present at the destination. By annotating those entities as eager or lazy, the code is copied across the network only if it is not present on the destination site.
The distributed garbage collection algorithm reclaims all unused entities except those forming a reference cycle that exists on at least two different owner sites (a cross-site cycle). For example, if two sites each own an object that references the other, then they will never be reclaimed. It is up to the programmer to break the cycle by updating one of the objects to no longer reference the other.
If a site crashes that has references to entities created on other sites, then these entities are not garbage-collected. A new distributed garbage collection scheme can recover from that situation; it is based on a time lease. Use the annotation lease to use that new scheme.
These affect what operations are available to the programmer. They document where the full language specification is not implemented. We hope that the undergrowth of limitations is sparse enough to let the flowers of Oz grow unwithered.1
On Windows, the Remote module has limited functionality. Only a single option is possible for fork, namely sh. Future releases will add more options.
The Connection module does not work correctly for applications separated by a firewall. This limitation will be addressed in a future release.
Threads, weak dictionaries, and spaces are sited, even though they are in base modules. However, dictionaries and arrays are no longer sited since version 1.4.0. Weak dictionaries have been kept sited so that their finalization mechanism relies on the garbage collector of a specific site. It is not known how to define finalization in case the state of the weak dictionary is replicated on several site.
When a reference to a constrained variable (finite domain, finite set, or free record) is passed to another site, then this reference is converted to a future. The future will be bound when the constrained variable becomes determined. Note that reference integrity is preserved: the future will be correctly identified as the original variable if it is sent back to its home site.
There is no modification to the formal semantics of the language.
| << Prev | - Up - | Next >> |