
<CHAPTER ID="chapter.limits">
  <TITLE>Limitations and Modifications</TITLE>

<P>The current release has the following limitations
and modifications with respect to the specifications
of the distribution model and the failure model.
A <EM>limitation</EM> is an operation that is specified
but is not possible or has lower performance
in the current release.
A <EM>modification</EM> is an operation that is specified
but behaves differently in the current release.

<P>Most of the limitations and modifications
listed here will be removed in future releases.

<SECTION><TITLE>Performance limitations</TITLE>

<P>These reduce performance but do not affect language semantics.
They can safely be ignored if performance is not an issue.

<list>
<item>The following problems
are related to the <<Remote>> module and virtual sites
(see also <ptr.extern to="ozdoc:system" key="chapter.remote">).
<list>
<item>On some platforms (in particular, Solaris),
the operating system in its default configuration
does not support virtual sites efficiently
(see also <ptr.extern to="ozdoc:system" key="chapter.remote">).
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.

<item>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>>.
</list>

<item>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.

<item>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 <EM>cross-site cycle</EM>).
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.

<item>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.
</list>

<SECTION><TITLE>Functionality limitations</TITLE>

<P>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.<NOTE
FOOT>C. A. R. Hoare, <em>The Emperor's Old Clothes</em>,
1980 Turing Award Lecture.</NOTE>

<list>
<item>On Windows, the <<Remote>> module has limited functionality.
Only a single option is possible for <<fork>>, namely <<sh>>.
Future releases will add more options.

<item>The <<Connection>> module does not work correctly
for applications separated by a firewall.
This limitation will be addressed in a future release.

<item>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.

<item>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 <em>future</em>.
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.
</list>

<SECTION><TITLE>Modifications</TITLE>

<P>There is no modification to the formal semantics of the language.

</CHAPTER>


