1Stdlib.Gc(3)                     OCaml library                    Stdlib.Gc(3)
2
3
4

NAME

6       Stdlib.Gc - no description
7

Module

9       Module   Stdlib.Gc
10

Documentation

12       Module Gc
13        : (module Stdlib__Gc)
14
15
16
17
18
19
20
21       type stat = {
22        minor_words  : float ;  (* Number of words allocated in the minor heap
23       since the program was started.
24        *)
25        promoted_words : float ;  (* Number of words allocated  in  the  minor
26       heap  that survived a minor collection and were moved to the major heap
27       since the program was started.
28        *)
29        major_words : float ;  (* Number of words allocated in the major heap,
30       including the promoted words, since the program was started.
31        *)
32        minor_collections  :  int  ;  (* Number of minor collections since the
33       program was started.
34        *)
35        major_collections : int ;  (* Number of major collection  cycles  com‐
36       pleted since the program was started.
37        *)
38        heap_words : int ;  (* Total size of the major heap, in words.
39        *)
40        heap_chunks  :  int  ;   (* Number of contiguous pieces of memory that
41       make up the major heap.
42        *)
43        live_words : int ;  (* Number of words of live data in the major heap,
44       including the header words.
45        *)
46        live_blocks : int ;  (* Number of live blocks in the major heap.
47        *)
48        free_words : int ;  (* Number of words in the free list.
49        *)
50        free_blocks : int ;  (* Number of blocks in the free list.
51        *)
52        largest_free  :  int ;  (* Size (in words) of the largest block in the
53       free list.
54        *)
55        fragments : int ;  (* Number of wasted  words  due  to  fragmentation.
56       These are 1-words free blocks placed between two live blocks.  They are
57       not available for allocation.
58        *)
59        compactions : int ;  (* Number of heap compactions since  the  program
60       was started.
61        *)
62        top_heap_words  : int ;  (* Maximum size reached by the major heap, in
63       words.
64        *)
65        stack_size : int ;  (* Current size of the stack, in words.
66
67
68       Since 3.12.0
69        *)
70        forced_major_collections : int ;  (* Number of forced full major  col‐
71       lections completed since the program was started.
72
73
74       Since 4.12.0
75        *)
76        }
77
78
79       The memory management counters are returned in a stat record.
80
81       The  total  amount  of  memory  allocated  by  the program since it was
82       started is (in words) minor_words  +  major_words  -  promoted_words  .
83       Multiply  by  the  word  size (4 on a 32-bit machine, 8 on a 64-bit ma‐
84       chine) to get the number of bytes.
85
86
87       type control = {
88
89       mutable minor_heap_size : int ;  (* The size (in words)  of  the  minor
90       heap.   Changing  this  parameter will trigger a minor collection.  De‐
91       fault: 256k.
92        *)
93
94       mutable major_heap_increment : int ;  (* How much to add to  the  major
95       heap  when increasing it. If this number is less than or equal to 1000,
96       it is a percentage of the current heap size (i.e.  setting  it  to  100
97       will  double  the heap size at each increase). If it is more than 1000,
98       it is a fixed number of words that will be added to the heap.  Default:
99       15.
100        *)
101
102       mutable  space_overhead : int ;  (* The major GC speed is computed from
103       this parameter.  This is the memory that will be "wasted"  because  the
104       GC does not immediately collect unreachable blocks.  It is expressed as
105       a percentage of the memory used for live data.  The GC will  work  more
106       (use  more  CPU time and collect blocks more eagerly) if space_overhead
107       is smaller.  Default: 120.
108        *)
109
110       mutable verbose : int ;  (* This value  controls  the  GC  messages  on
111       standard  error output.  It is a sum of some of the following flags, to
112       print messages on the corresponding events:
113
114       - 0x001 Start and end of major GC cycle.
115
116       - 0x002 Minor collection and major GC slice.
117
118       - 0x004 Growing and shrinking of the heap.
119
120       - 0x008 Resizing of stacks and memory manager tables.
121
122       - 0x010 Heap compaction.
123
124       - 0x020 Change of GC parameters.
125
126       - 0x040 Computation of major GC slice size.
127
128       - 0x080 Calling of finalisation functions.
129
130       - 0x100 Bytecode executable and shared library search at start-up.
131
132       - 0x200 Computation of compaction-triggering condition.
133
134       - 0x400 Output GC statistics at program exit.  Default: 0.
135
136        *)
137
138       mutable max_overhead : int ;  (* Heap compaction is triggered when  the
139       estimated  amount  of "wasted" memory is more than max_overhead percent
140       of the amount of live data.  If max_overhead is set  to  0,  heap  com‐
141       paction is triggered at the end of each major GC cycle (this setting is
142       intended for testing purposes only).  If max_overhead >= 1000000 , com‐
143       paction  is never triggered.  If compaction is permanently disabled, it
144       is strongly suggested to set allocation_policy to 2.  Default: 500.
145        *)
146
147       mutable stack_limit : int ;  (* The  maximum  size  of  the  stack  (in
148       words).   This is only relevant to the byte-code runtime, as the native
149       code runtime uses the operating system's stack.  Default: 1024k.
150        *)
151
152       mutable allocation_policy : int ;  (* The policy used for allocating in
153       the major heap.  Possible values are 0, 1 and 2.
154
155
156       -0  is  the  next-fit  policy,  which is usually fast but can result in
157       fragmentation, increasing memory consumption.
158
159
160       -1 is the first-fit policy, which avoids fragmentation but  has  corner
161       cases (in certain realistic workloads) where it is sensibly slower.
162
163
164       -2  is  the best-fit policy, which is fast and avoids fragmentation. In
165       our experiments it is faster and uses less memory  than  both  next-fit
166       and first-fit.  (since OCaml 4.10)
167
168       The default is best-fit.
169
170       On  one  example  that  was known to be bad for next-fit and first-fit,
171       next-fit takes 28s using 855Mio of memory, first-fit  takes  47s  using
172       566Mio of memory, best-fit takes 27s using 545Mio of memory.
173
174       Note: If you change to next-fit, you may need to reduce the space_over‐
175       head setting, for example using 80 instead of the default 120 which  is
176       tuned for best-fit. Otherwise, your program will need more memory.
177
178       Note:  changing  the  allocation  policy at run-time forces a heap com‐
179       paction, which is a lengthy operation unless the heap is small (e.g. at
180       the start of the program).
181
182       Default: 2.
183
184
185       Since 3.11.0
186        *)
187        window_size  :  int  ;  (* The size of the window used by the major GC
188       for smoothing out variations in its workload. This is  an  integer  be‐
189       tween 1 and 50.  Default: 1.
190
191
192       Since 4.03.0
193        *)
194        custom_major_ratio : int ;  (* Target ratio of floating garbage to ma‐
195       jor heap size for out-of-heap memory held by custom values  located  in
196       the major heap. The GC speed is adjusted to try to use this much memory
197       for dead values that are not yet collected. Expressed as  a  percentage
198       of  major  heap  size. The default value keeps the out-of-heap floating
199       garbage about the same size as the in-heap overhead.  Note:  this  only
200       applies  to  values  allocated  with caml_alloc_custom_mem (e.g. bigar‐
201       rays).  Default: 44.
202
203
204       Since 4.08.0
205        *)
206        custom_minor_ratio  :  int  ;   (*  Bound  on  floating  garbage   for
207       out-of-heap  memory held by custom values in the minor heap. A minor GC
208       is triggered when this much memory is held by custom values located  in
209       the  minor  heap.  Expressed as a percentage of minor heap size.  Note:
210       this only applies to values allocated with caml_alloc_custom_mem  (e.g.
211       bigarrays).  Default: 100.
212
213
214       Since 4.08.0
215        *)
216        custom_minor_max_size : int ;  (* Maximum amount of out-of-heap memory
217       for each custom value allocated in the minor heap. When a custom  value
218       is  allocated  on  the  minor heap and holds more than this many bytes,
219       only this value is counted against custom_minor_ratio and the  rest  is
220       directly  counted against custom_major_ratio .  Note: this only applies
221       to values allocated with caml_alloc_custom_mem (e.g.  bigarrays).   De‐
222       fault: 8192 bytes.
223
224
225       Since 4.08.0
226        *)
227        }
228
229
230       The  GC  parameters are given as a control record.  Note that these pa‐
231       rameters can also be initialised by setting the OCAMLRUNPARAM  environ‐
232       ment variable.  See the documentation of ocamlrun .
233
234
235
236       val stat : unit -> stat
237
238       Return  the  current values of the memory management counters in a stat
239       record.  This function examines every heap block to get the statistics.
240
241
242
243       val quick_stat : unit -> stat
244
245       Same as stat except  that  live_words  ,  live_blocks  ,  free_words  ,
246       free_blocks , largest_free , and fragments are set to 0.  This function
247       is much faster than stat because it does not need  to  go  through  the
248       heap.
249
250
251
252       val counters : unit -> float * float * float
253
254       Return  (minor_words,  promoted_words, major_words) .  This function is
255       as fast as quick_stat .
256
257
258
259       val minor_words : unit -> float
260
261       Number of words allocated in the  minor  heap  since  the  program  was
262       started. This number is accurate in byte-code programs, but only an ap‐
263       proximation in programs compiled to native code.
264
265       In native code this function does not allocate.
266
267
268       Since 4.04
269
270
271
272       val get : unit -> control
273
274       Return the current values of the GC parameters in a control record.
275
276
277
278       val set : control -> unit
279
280
281       set r changes the GC parameters according to the  control  record  r  .
282       The normal usage is: Gc.set { (Gc.get()) with Gc.verbose = 0x00d }
283
284
285
286
287       val minor : unit -> unit
288
289       Trigger a minor collection.
290
291
292
293       val major_slice : int -> int
294
295
296       major_slice n Do a minor collection and a slice of major collection.  n
297       is the size of the slice: the GC will do enough work to free (on  aver‐
298       age)  n words of memory. If n = 0, the GC will try to do enough work to
299       ensure that the next automatic slice has no work to do.  This  function
300       returns an unspecified integer (currently: 0).
301
302
303
304       val major : unit -> unit
305
306       Do a minor collection and finish the current major collection cycle.
307
308
309
310       val full_major : unit -> unit
311
312       Do  a  minor collection, finish the current major collection cycle, and
313       perform a complete new cycle.  This will collect all currently unreach‐
314       able blocks.
315
316
317
318       val compact : unit -> unit
319
320       Perform  a  full major collection and compact the heap.  Note that heap
321       compaction is a lengthy operation.
322
323
324
325       val print_stat : out_channel -> unit
326
327       Print the current values of the  memory  management  counters  (in  hu‐
328       man-readable form) into the channel argument.
329
330
331
332       val allocated_bytes : unit -> float
333
334       Return  the  total  number  of  bytes  allocated  since the program was
335       started.  It is returned as a float to avoid overflow problems with int
336       on 32-bit machines.
337
338
339
340       val get_minor_free : unit -> int
341
342       Return the current size of the free space inside the minor heap.
343
344
345       Since 4.03.0
346
347
348
349       val get_bucket : int -> int
350
351
352       get_bucket n returns the current size of the n -th future bucket of the
353       GC smoothing system. The unit is one millionth of a full GC.
354
355
356       Since 4.03.0
357
358
359       Raises Invalid_argument if n is negative, return 0 if n is larger  than
360       the smoothing window.
361
362
363
364       val get_credit : unit -> int
365
366
367       get_credit  ()  returns  the current size of the "work done in advance"
368       counter of the GC smoothing system. The unit is one millionth of a full
369       GC.
370
371
372       Since 4.03.0
373
374
375
376       val huge_fallback_count : unit -> int
377
378       Return  the  number of times we tried to map huge pages and had to fall
379       back to small pages. This is always 0 if OCAMLRUNPARAM contains H=1 .
380
381
382       Since 4.03.0
383
384
385
386       val finalise : ('a -> unit) -> 'a -> unit
387
388
389       finalise f v registers f as a finalisation function for v .  v must  be
390       heap-allocated.   f will be called with v as argument at some point be‐
391       tween the first time v  becomes  unreachable  (including  through  weak
392       pointers)  and the time v is collected by the GC. Several functions can
393       be registered for the same value, or even several instances of the same
394       function.   Each instance will be called once (or never, if the program
395       terminates before v becomes unreachable).
396
397       The GC will call the finalisation functions in the order  of  dealloca‐
398       tion.   When  several  values become unreachable at the same time (i.e.
399       during the same GC cycle), the finalisation functions will be called in
400       the reverse order of the corresponding calls to finalise .  If finalise
401       is called in the same order as the values  are  allocated,  that  means
402       each  value is finalised before the values it depends upon.  Of course,
403       this becomes false if additional dependencies are introduced by assign‐
404       ments.
405
406       In the presence of multiple OCaml threads it should be assumed that any
407       particular finaliser may be executed in any of the threads.
408
409       Anything reachable from the closure of finalisation functions  is  con‐
410       sidered reachable, so the following code will not work as expected:
411
412       - let v = ... in Gc.finalise (fun _ -> ...v...) v
413
414       Instead you should make sure that v is not in the closure of the final‐
415       isation function by writing:
416
417       - let f = fun x -> ...  let v = ... in Gc.finalise f v
418
419       The f function can use all features  of  OCaml,  including  assignments
420       that make the value reachable again.  It can also loop forever (in this
421       case, the other finalisation functions will not be  called  during  the
422       execution  of  f,  unless it calls finalise_release ).  It can call fi‐
423       nalise on v or other values to register other functions or even itself.
424       It  can  raise  an exception; in this case the exception will interrupt
425       whatever the program was doing when the function was called.
426
427
428       finalise will raise Invalid_argument if  v  is  not  guaranteed  to  be
429       heap-allocated.   Some  examples  of values that are not heap-allocated
430       are integers, constant constructors, booleans,  the  empty  array,  the
431       empty  list,  the unit value.  The exact list of what is heap-allocated
432       or not  is  implementation-dependent.   Some  constant  values  can  be
433       heap-allocated  but  never  deallocated during the lifetime of the pro‐
434       gram, for example a list of integer constants; this is also implementa‐
435       tion-dependent.   Note  that  values of types float are sometimes allo‐
436       cated and sometimes not, so finalising them  is  unsafe,  and  finalise
437       will  also  raise  Invalid_argument  for them. Values of type 'a Lazy.t
438       (for any 'a ) are like float in this respect, except that the  compiler
439       sometimes optimizes them in a way that prevents finalise from detecting
440       them. In this case, it will not raise Invalid_argument , but you should
441       still avoid calling finalise on lazy values.
442
443       The  results  of  calling String.make , Bytes.make , Bytes.create , Ar‐
444       ray.make , and ref are guaranteed to be heap-allocated and non-constant
445       except when the length argument is 0 .
446
447
448
449       val finalise_last : (unit -> unit) -> 'a -> unit
450
451       same  as  Gc.finalise except the value is not given as argument. So you
452       can't use the given value for the computation of the finalisation func‐
453       tion. The benefit is that the function is called after the value is un‐
454       reachable for the last time instead of the first time. So  contrary  to
455       Gc.finalise  the  value will never be reachable again or used again. In
456       particular every weak pointer and ephemeron that contained  this  value
457       as key or data is unset before running the finalisation function. More‐
458       over the finalisation functions attached with  Gc.finalise  are  always
459       called before the finalisation functions attached with Gc.finalise_last
460       .
461
462
463       Since 4.04
464
465
466
467       val finalise_release : unit -> unit
468
469       A finalisation function may call finalise_release to tell the  GC  that
470       it  can  launch  the next finalisation function without waiting for the
471       current one to return.
472
473
474       type alarm
475
476
477       An alarm is a piece of data that calls a user function at  the  end  of
478       each  major  GC  cycle.  The following functions are provided to create
479       and delete alarms.
480
481
482
483       val create_alarm : (unit -> unit) -> alarm
484
485
486       create_alarm f will arrange for f to be called at the end of each major
487       GC  cycle, starting with the current cycle or the next one.  A value of
488       type alarm is returned that you can use to call delete_alarm .
489
490
491
492       val delete_alarm : alarm -> unit
493
494
495       delete_alarm a will stop the calls to the function associated  to  a  .
496       Calling delete_alarm a again has no effect.
497
498
499
500       val eventlog_pause : unit -> unit
501
502
503       eventlog_pause  ()  will pause the collection of traces in the runtime.
504       Traces are collected if the program is linked to the instrumented  run‐
505       time  and started with the environment variable OCAML_EVENTLOG_ENABLED.
506       Events are flushed to disk after pausing, and no  new  events  will  be
507       recorded until eventlog_resume is called.
508
509
510
511       val eventlog_resume : unit -> unit
512
513
514       eventlog_resume () will resume the collection of traces in the runtime.
515       Traces are collected if the program is linked to the instrumented  run‐
516       time  and started with the environment variable OCAML_EVENTLOG_ENABLED.
517       This call can be used after calling eventlog_pause , or if the  program
518       was started with OCAML_EVENTLOG_ENABLED=p. (which pauses the collection
519       of traces before the first event.)
520
521
522       module Memprof : sig end
523
524
525
526       Memprof is a sampling engine for allocated memory  words.  Every  allo‐
527       cated  word  has a probability of being sampled equal to a configurable
528       sampling rate. Once a block is sampled, it becomes tracked.  A  tracked
529       block triggers a user-defined callback as soon as it is allocated, pro‐
530       moted or deallocated.
531
532       Since blocks are composed of several words, a block can potentially  be
533       sampled  several  times. If a block is sampled several times, then each
534       of the callback is called once for each event of this block: the multi‐
535       plicity is given in the n_samples field of the allocation structure.
536
537       This  engine  makes it possible to implement a low-overhead memory pro‐
538       filer as an OCaml library.
539
540       Note: this API is EXPERIMENTAL. It may change without prior notice.
541
542
543
544
545
546OCamldoc                          2022-02-04                      Stdlib.Gc(3)
Impressum