<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Mozart System Limitations</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><P class="margin"><A href="../index.html">Top</A></P><H1 align="center" class="title">Mozart System Limitations</H1><HR><UL class="toc"><LI><A href="index.html#label1">Limitations</A><UL class="toc"><LI><A href="index.html#label2">Maximum Memory Size</A></LI><LI><A href="index.html#label3">Garbage Collection</A></LI><LI><A href="index.html#label4">Cloning</A></LI><LI><A href="index.html#label5">Choice Points</A></LI><LI><A href="index.html#label6">Constraint Variables Across Spaces</A></LI><LI><A href="index.html#label7">Record Arities</A></LI><LI><A href="index.html#label8">Procedures</A></LI><LI><A href="index.html#label9">Finite Domains and Finite Sets</A></LI><LI><A href="index.html#label10">Integers and Floats</A></LI><LI><A href="index.html#label11">Compiler</A></LI><LI><A href="index.html#label12">Distribution</A></LI></UL></LI></UL><HR><DIV class="unnumbered"><H1><A name="label1">Limitations</A></H1><P>In general, Mozart has very few system limitations. Memory allocation is dynamic. The number of record fields, the size of arrays and dictionaries, the number of characters in an atom, the number of threads, integer precision, etc., are all limited only by available memory. Memory is requested from the operating system according to need. The allocation strategy is user-customizable (see <A href="../system/node58.html#chapter.property">Chapter 23 of ``System Modules''</A>). If memory use decreases, then all unused memory is eventually returned to the operating system. </P><P>However, a few limits remain. </P><DIV class="unnumbered"><H2><A name="label2">Maximum Memory Size</A></H2><P>Mozart has been ported to 32-bit and 64-bit architectures. On 32-bit architectures, a program can use all available memory (that is 4GB) which in the worst case (due to copying garbage collection) means that Mozart can have an active heap (that is alive data structures) of 2GB. This is currently also shared with 64-bit architectures.</P><P>A crude but effective way to go beyond this limit is to use the <CODE>Remote</CODE> module to create new sites (i.e., OS processes). This is especially effective if communication to the new processes is by shared memory. For more information on <CODE>Remote</CODE>, see <A href="../system/node48.html#chapter.remote">Chapter 13 of ``System Modules''</A>. </P></DIV><DIV class="unnumbered"><H2><A name="label3">Garbage Collection</A></H2><P>All memory areas of the virtual machine are garbage collected except for the atom table and the table of record arities. In particular, the area used to store program instructions is garbage collected.</P><P>We recommend to avoid as much as possible dynamically creating atoms (with <CODE>String<SPAN class="keyword">.</SPAN>toAtom</CODE> or <CODE>VirtualString<SPAN class="keyword">.</SPAN>toAtom</CODE>) or records with new arities (for example, with <CODE>Record<SPAN class="keyword">.</SPAN>filter</CODE>). Tuples do not have entries in the arity table, so they are not subject to this restriction. </P></DIV><DIV class="unnumbered"><H2><A name="label4">Cloning</A></H2><P>Arities of records are not cloned. This is typically correct. Only if the arity contains names that are local to a subordinated space this is incorrect. </P></DIV><DIV class="unnumbered"><H2><A name="label5">Choice Points</A></H2><P>The number of alternatives of a choice point must be less than <IMG alt="2^{27}-2" src="latex1.png"> (i.e., 134217726). </P></DIV><DIV class="unnumbered"><H2><A name="label6">Constraint Variables Across Spaces</A></H2><P>The following restriction is very, very, very small! The implementation does currently not support that a so-far unconstrained variable is locally (inside a local computation space or inside a guard of a combinator) constrained to a constraint-variable (for example, a finite domain variable). This can be avoided by constraining the variable globally to a constraint-variable. </P><P>For example, instead of </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">local</SPAN> X <SPAN class="keyword">in</SPAN> <SPAN class="keyword">or</SPAN> X<SPAN class="keyword">::</SPAN>1<SPAN class="keyword">#</SPAN>2 <SPAN class="keyword">[]</SPAN> X<SPAN class="keyword">::</SPAN>3<SPAN class="keyword">#</SPAN>4 <SPAN class="keyword">end</SPAN> <SPAN class="keyword">end</SPAN></CODE></BLOCKQUOTE><P> one should always use </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">local</SPAN> X={FD<SPAN class="keyword">.</SPAN>decl} <SPAN class="keyword">in</SPAN> <SPAN class="keyword">or</SPAN> X<SPAN class="keyword">::</SPAN>1<SPAN class="keyword">#</SPAN>2 <SPAN class="keyword">[]</SPAN> X<SPAN class="keyword">::</SPAN>3<SPAN class="keyword">#</SPAN>4 <SPAN class="keyword">end</SPAN> <SPAN class="keyword">end</SPAN></CODE></BLOCKQUOTE><P> </P></DIV><DIV class="unnumbered"><H2><A name="label7">Record Arities</A></H2><P>Arities of records are not cloned. This is typically correct. Only if the arity contains names that are local to a subordinated space this is incorrect. </P></DIV><DIV class="unnumbered"><H2><A name="label8">Procedures</A></H2><P>Procedures can have no more than 4096 arguments. </P></DIV><DIV class="unnumbered"><H2><A name="label9">Finite Domains and Finite Sets</A></H2><P>The range of a finite domain variable is from 0 to <IMG alt="2^{27}-2" src="latex1.png"> (i.e., 134217726).</P><P>The range of a finite set domain variable is from <IMG alt="\{\}" src="latex2.png"> to <IMG alt="\{0, ..., 2^{27}-2\}" src="latex3.png">. </P></DIV><DIV class="unnumbered"><H2><A name="label10">Integers and Floats</A></H2><P>Integers of 28-bit or less precision are stored in registers. Floating-point numbers and integers needing more than 28-bit precision are stored on the heap.</P><P>This means that calculations are significantly faster and memory-efficient when done with small integers rather than with floating-point numbers or big integers. </P></DIV><DIV class="unnumbered"><H2><A name="label11">Compiler</A></H2><P>The compiler is part of the interactive run-time system. It may use large amounts of memory on large programs or programs that access large data structures in the run-time environment. This memory use is temporary. After the compiler completes, the memory is eventually returned to the operating system. </P></DIV><DIV class="unnumbered"><H2><A name="label12">Distribution</A></H2><P>See the distribution tutorial <A href="../dstutorial/index.html">``Distributed Programming in Mozart - A Tutorial Introduction''</A> for a list of limitations related to distribution and fault tolerance. </P></DIV></DIV><HR><ADDRESS><SPAN class="version">Version 1.4.0 (20090610)</SPAN></ADDRESS></BODY></HTML>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
bd5c3d824c3db63ffd9226c15941e6ad
>
files
>
1444
