Lucas, It looks as though these are a long way out of date. The "Using Poly/ML" document really needs to be completely updated. The current settings can be found from "poly --help" which shows:
Compiler arguments:
-v Print the version of Poly/ML and exit --help Print this message and exit -q Suppress the start-up message --with-markup Include extra mark-up information when printing --ideprotocol Run the IDE communications protocol
Run time system arguments: -H <Initial heap size (MB)> --heap <Initial heap size (MB)> --immutable <Initial size of immutable buffer (MB)> --mutable <Initial size of mutable buffer(MB)> --debug <Debug options>
-H and --heap are the same. The mutable and immutable heap segments (not really "buffers") are used for allocation and garbage-collection. If neither of these is specified explicitly the mutable segment size is set to a fifth of the heap size and the immutable segment size to four-fifths. If no heap size is specified the default is half the physical memory on the machine. At start-up one mutable and one immutable segment are created. Initially cells are allocated in the mutable segment until this is full. Then a minor garbage-collection is started that copies all the immutable data (lists, tuples, closures) into the immutable area and compacts the remaining mutable data (refs, arrays and stacks) within the mutable area. Then execution is resumed, again allocating in the mutable area. Eventually either the mutable or immutable area will become sufficiently full that a full GC is needed. If the full GC does not produce enough free space then either or both of the mutable and immutable areas may be extended by allocating another segment of the same size as the original segment.
So, the heap segment sizes define the sizes of the initial segments but also the increments by which the heap may grow. In effect the mutable segment size controls how frequently minor GCs occur and the immutable segment size controls the frequency of major (full) GCs.
There's no way at the moment to get statistics on what is happening in the memory. I did think about this one. In Windows perfmon can be used to view statistics from all sorts of programs and parts of the OS in a single graph and it would be possible to provide a plug-in to provide this for Poly/ML. There's a standard interface between perfmon and the plug-ins. I don't know of anything similar for Linux.
timeslice is no longer relevant. It was there in the old single-processor version.
Regards, David
Lucas Dixon wrote:
I have a couple of quick questions, mostly based on observing that http://www.polyml.org/docs/HeapParms9.html could do with being updated. Looking at the poly man page, I feel it is a little brief on the descriptions, these are the questions that came to mind when I was about to explain it to someone else...
"man poly" tells me:
-H size Set the initial heap size, in MB. --heap size Set the initial heap size, in MB.is this then the same as -H? Given that the heap size is described as being initial, does it increase as PolyML is running? I was under the (probably wrong) impression that PolyML has a fixed heap size.
--immutable size Set the size of the immutables buffer, in MB. --mutable size Set the size of the mutables buffer, in MB.Are these limits? Can they be edited while PolyML is running?
--timeslice timeslice Set the timeslice.Can someone remind me what this is?
I was also curious if there a way to get PolyML to print/edit out it's current memory parameters while it is running?
cheers, lucas