memory.size(maximum=F)
On UNIX, memory.size() reports the difference between the top of the heap
at a certain point in Splus's initilization code and the top of
the heap when memory.size() is called. On Windows, it reports the
tolal heap size dynamically allocated by S-PLUS. Thus it should always report
something less than what the OS reports.
The OS generally reports size based on the total 'data segment'
size. The data segment consists of the fixed memory (compiled
into the executable) plus the heap (the expandable part). memory.size()
is trying to report just the heap size.
On Unix the initial heap size depends on whether we are using the
Java GUI (Splus -g), the Java command line interface (Splus -j),
or no Java at all. A lot of Java code is executed (and lots of
Java objects are made) before we record the initial top of heap value.
(NOTE: the Java GUI is deprecated in S-PLUS 8.1.)
On most UNIX machines S-PLUS will not shrink its data space when its requirements
decrease. For example under a SUN Solaris, S-PLUS cannot shrink
the data space so memory.size() will return the same answer regardless
of the value of
maximum
.
Under Windows NT/2000, if it is able to shrink the data space, it
will try to shrink it at the end of each top level expression.
The size returned is the size of the space used for dynamically allocated
memory. It does not include the space used for the executable code or
compiled in data, which totals about 3 megabytes on most machines.
It does include the unallocated space between allocated blocks of memory.
If the total amount of space used by S-PLUS is larger than your available
main memory, S-PLUS will dramatically slow down as it spends most of
its time transferring the excess to and from the swap disk.
You may need to quit from S-PLUS and restart in order to avoid this.
memory.size() [1] 428152 { sum(log(1:1e5)) ; memory.size() } [1] 2033784 # grew from 0.4 to 2 megabytes memory.size() [1] 828208 # shrank to 0.8 megabytes memory.size(max=T) [1] 2033784