module Pool_intf:sig
..end
A pool stores a bounded-size set of tuples, where client code is responsible for
explicitly controlling when the pool allocates and frees tuples. One create
s a pool
of a certain capacity, which returns an empty pool that can hold that many tuples.
One then uses new
to allocate a tuple, which returns a Pointer.t
to the tuple.
One then uses get
and set
along with the pointer to get and set slots of the
tuple. Finally, one free
's a pointer to the pool's memory for a tuple, making the
memory available for subsequent reuse.
The point of Pool
is to allocate a single long-lived block of memory (the pool) that
lives in the OCaml major heap, and then to reuse the block, rather than continually
allocating blocks on the minor heap.
In typical usage, one wraps up a pool with an abstract interface, giving nice names to the tuple slots, and only exposing mutation where desired.
All the usual problems with manual memory allocation are present with pools:
Pool.Error_check
, that is useful for building pools
to help debug incorrect pointer usage.
A pool stores a bounded-size set of tuples, where client code is responsible for
explicitly controlling when the pool allocates and frees tuples. One create
s a pool
of a certain capacity, which returns an empty pool that can hold that many tuples.
One then uses new
to allocate a tuple, which returns a Pointer.t
to the tuple.
One then uses get
and set
along with the pointer to get and set slots of the
tuple. Finally, one free
's a pointer to the pool's memory for a tuple, making the
memory available for subsequent reuse.
The point of Pool
is to allocate a single long-lived block of memory (the pool) that
lives in the OCaml major heap, and then to reuse the block, rather than continually
allocating blocks on the minor heap.
In typical usage, one wraps up a pool with an abstract interface, giving nice names to the tuple slots, and only exposing mutation where desired.
All the usual problems with manual memory allocation are present with pools:
Pool.Error_check
, that is useful for building pools
to help debug incorrect pointer usage.module type S =sig
..end
S
is the module type for a pool.
module type Pool =sig
..end
A pool stores a bounded-size set of tuples, where client code is responsible for
explicitly controlling when the pool allocates and frees tuples. One create
s a pool
of a certain capacity, which returns an empty pool that can hold that many tuples.
One then uses new
to allocate a tuple, which returns a Pointer.t
to the tuple.
One then uses get
and set
along with the pointer to get and set slots of the
tuple. Finally, one free
's a pointer to the pool's memory for a tuple, making the
memory available for subsequent reuse.
The point of Pool
is to allocate a single long-lived block of memory (the pool) that
lives in the OCaml major heap, and then to reuse the block, rather than continually
allocating blocks on the minor heap.
In typical usage, one wraps up a pool with an abstract interface, giving nice names to the tuple slots, and only exposing mutation where desired.
All the usual problems with manual memory allocation are present with pools:
Pool.Error_check
, that is useful for building pools
to help debug incorrect pointer usage.S
is the module type for a pool.'slots
will look like ('a1, ..., 'an)
Slots.tn
, and the tuples have type 'a1 * ... * 'an
.null
pointer is a distinct pointer that does not correspond to a tuple in
the pool. It is a function to prevent problems due to the value restriction.'slots
will look like ('a1, ..., 'an) Slots.tn
, and the pool holds
tuples of type 'a1 * ... * 'an
.pointer_is_valid t pointer
returns true
iff pointer
points to a live tuple in
t
, i.e. pointer
is not null, not free, and is in the range of t
.
A pointer might not be in the range of a pool if it comes from another pool for
example. In this case unsafe_get/set functions would cause a segfault.
id_of_pointer t pointer
returns an id that is unique for the lifetime of
pointer
's tuple. When the tuple is freed, the id is no longer valid, and
pointer_of_id_exn
will fail on it. Pointer.null ()
has a distinct id from all
non-null pointers.
pointer_of_id_exn t id
returns the pointer corresponding to id
. It fails if the
tuple corresponding to id
was already free
d.
pointer_of_id_exn_is_supported
says whether the implementation supports
pointer_of_id_exn
; if not, it will always raise. We can not use the usual idiom
of making pointer_of_id_exn
be an Or_error.t
due to problems with the value
restriction.
create slots ~capacity ~dummy
creates an empty pool that can hold up to capacity
N-tuples. The slots of dummy
are stored in free tuples. create
raises if
capacity < 0
.
capacity
returns the maximum number of tuples that the pool can hold.
length
returns the number of tuples currently in the pool.
0 <= length t <= capacity t
grow t ~capacity
returns a new pool t'
with the supplied capacity. The new pool
is to be used as a replacement for t
. All live tuples in t
are now live in
t'
, and valid pointers to tuples in t
are now valid pointers to the identical
tuple in t'
. It is an error to use t
after calling grow t
.
grow
raises if the supplied capacity isn't larger than capacity t
.
default is 2 * capacity t
is_full t
returns true
if no more tuples can be allocated in t
.
free t pointer
frees the tuple pointed to by pointer
from t
.
unsafe_free t pointer
frees the tuple pointed to by pointer
without checking
pointer_is_valid
new<N> t a0 ... a<N-1>
returns a new tuple from the pool, with the tuple's
slots initialized to a0
... a<N-1>
. new
raises if is_full t
.
get_tuple t pointer
allocates an OCaml tuple isomorphic to the pool t
's tuple
pointed to by pointer
. The tuple gets copied, but its slots do not.
get t pointer slot
gets slot
of the tuple pointed to by pointer
in
pool t
.
set t pointer slot a
sets to a
the slot
of the tuple pointed to by pointer
in pool t
.
In get
and set
, it is an error to refer to a pointer that has been free
d. It
is also an error to use a pointer with any pool other than the one the pointer was
new
'd from or grow
n to. These errors will lead to undefined behavior, but will
not segfault.
unsafe_get
is comparable in speed to get
for immediate values, and 5%-10% faster
for pointers.
unsafe_get
and unsafe_set
skip bounds checking, and can thus segfault.
This uses an Obj_array.t
to implement the pool. We expose that Pointer.t
is an
int
so that OCaml can avoid the write barrier, due to knowing that Pointer.t
isn't an OCaml pointer.
An Unsafe
pool is like an ordinary pool, except that the create
function does
not require an initial element. The pool stores Obj.magic ()
as the dummy value
for each slot. Such a pool is only safe if one never accesses a slot from a free
d
tuple.
It makes sense to use Unsafe
if one has a small constrained chunk of code where
one can prove that one never accesses a free
d tuple, and one needs a pool where
it is difficult to construct a dummy value.
create slots ~capacity
creates an empty pool that can hold up to capacity
N-tuples. The elements of a free
tuple may contain stale and/or invalid values
for their types, and as such any access to a free
tuple from this pool is
unsafe.
Debug
builds a pool in which every function can run invariant
on its pool
argument(s) and/or print a debug message to stderr, as determined by
!check_invariant
and !show_messages
, which are initially both true
.
The performance of the pool resulting from Debug
is much worse than that of the
input Pool
, even with all the controls set to false
.
Error_check
builds a pool that has additional error checking for pointers, in
particular to detect using a free
d pointer or multiply free
ing a pointer.
Error_check
has a significant performance cost, but less than that of Debug
.
One can compose Debug
and Error_check
, e.g:
module M = Debug (Error_check (Obj_array))