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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
