Skip to content

Commit 36ad2ce

Browse files
Fix misspells in the repo
Partially found with aspell.
1 parent 0b11d42 commit 36ad2ce

File tree

5 files changed

+5
-5
lines changed

5 files changed

+5
-5
lines changed

scripts/docs_config/api.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -148,7 +148,7 @@ Mempolicy
148148
Memtarget
149149
==========================================
150150

151-
TODO: Add general information about memtarges.
151+
TODO: Add general information about memtargets.
152152

153153
Memtarget
154154
------------------------------------------

scripts/docs_config/introduction.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ defined pool allocators if they implement the UMF interface.
9999
Memory Pools
100100
============
101101

102-
A memory pool consists of a pool allocator and a memory provider instancies
102+
A memory pool consists of a pool allocator and a memory provider instances
103103
along with their properties and allocation policies. Memory pools are used by
104104
the :ref:`allocation API <allocation API>` as a first argument. There is also a possibility to
105105
retrieve a memory pool from an existing memory pointer that points to a memory

src/ipc.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -109,7 +109,7 @@ umf_result_t umfPutIPCHandle(umf_ipc_handle_t umfIPCHandle) {
109109
// implementation does nothing in Put function. Tracking memory
110110
// provider relies on IPC cache and actually Put IPC handle back
111111
// to upstream memory provider when umfMemoryProviderFree is called.
112-
// To support incapsulation we should not take into account
112+
// To support encapsulation we should not take into account
113113
// implementation details of tracking memory provider and find the
114114
// appropriate pool, get memory provider of that pool and call
115115
// umfMemoryProviderPutIPCHandle(hProvider,

src/pool/pool_disjoint.cpp

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -237,7 +237,7 @@ class Bucket {
237237
// When a slab becomes entirely free we have to decide whether to return it
238238
// to the provider or keep it allocated. A simple check for size of the
239239
// Available list is not sufficient to check whether any slab has been
240-
// pooled yet.We would have to traverse the entire Available listand check
240+
// pooled yet. We would have to traverse the entire Available list and check
241241
// if any of them is entirely free. Instead we keep a counter of entirely
242242
// empty slabs within the Available list to speed up the process of checking
243243
// if a slab in this bucket is already pooled.

src/pool/pool_jemalloc.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -203,7 +203,7 @@ static bool arena_extent_decommit(extent_hooks_t *extent_hooks, void *addr,
203203
// physical pages within the virtual memory mapping associated with an extent at given addr and size
204204
// at offset bytes, extending for length on behalf of arena arena_ind. A lazy extent purge function
205205
// (e.g. implemented via madvise(...MADV_FREE)) can delay purging indefinitely and leave the pages
206-
// within the purged virtual memory range in an indeterminite state, whereas a forced extent purge
206+
// within the purged virtual memory range in an indeterminate state, whereas a forced extent purge
207207
// function immediately purges, and the pages within the virtual memory range will be zero-filled
208208
// the next time they are accessed. If the function returns true, this indicates failure to purge.
209209
// (from https://jemalloc.net/jemalloc.3.html)

0 commit comments

Comments
 (0)