Module Gc.Control

module Control: sig .. end

type t = {
   mutable minor_heap_size :int; (*The size (in words) of the minor heap. Changing this parameter will trigger a minor collection. Default: 32k.*)
   mutable major_heap_increment :int; (*The minimum number of words to add to the major heap when increasing it. Default: 62k.*)
   mutable space_overhead :int; (*The major GC speed is computed from this parameter. This is the memory that will be "wasted" because the GC does not immediatly collect unreachable blocks. It is expressed as a percentage of the memory used for live data. The GC will work more (use more CPU time and collect blocks more eagerly) if space_overhead is smaller. Default: 80.*)
   mutable verbose :int; (*This value controls the GC messages on standard error output. It is a sum of some of the following flags, to print messages on the corresponding events:
  • 0x001 Start of major GC cycle.
  • 0x002 Minor collection and major GC slice.
  • 0x004 Growing and shrinking of the heap.
  • 0x008 Resizing of stacks and memory manager tables.
  • 0x010 Heap compaction.
  • 0x020 Change of GC parameters.
  • 0x040 Computation of major GC slice size.
  • 0x080 Calling of finalisation functions.
  • 0x100 Bytecode executable search at start-up.
  • 0x200 Computation of compaction triggering condition. Default: 0.
*)
   mutable max_overhead :int; (*Heap compaction is triggered when the estimated amount of "wasted" memory is more than max_overhead percent of the amount of live data. If max_overhead is set to 0, heap compaction is triggered at the end of each major GC cycle (this setting is intended for testing purposes only). If max_overhead >= 1000000, compaction is never triggered. Default: 500.*)
   mutable stack_limit :int; (*The maximum size of the stack (in words). This is only relevant to the byte-code runtime, as the native code runtime uses the operating system's stack. Default: 256k.*)
   mutable allocation_policy :int; (*The policy used for allocating in the heap. Possible values are 0 and 1. 0 is the next-fit policy, which is quite fast but can result in fragmentation. 1 is the first-fit policy, which can be slower in some cases but can be better for programs with fragmentation problems. Default: 0.*)
}
include Binable.S
include Sexpable.S