File 1310-Fix-typos-in-erts-emulator-internal_doc.patch of Package erlang
From c2a320a122e3c73eb93a9ac05d2fce9d45702196 Mon Sep 17 00:00:00 2001
From: "Kian-Meng, Ang" <kianmeng@cpan.org>
Date: Wed, 24 Nov 2021 13:06:14 +0800
Subject: [PATCH] Fix typos in erts/emulator/internal_doc/
---
erts/emulator/internal_doc/BeamAsm.md | 2 +-
erts/emulator/internal_doc/CodeLoading.md | 2 +-
erts/emulator/internal_doc/DelayedDealloc.md | 4 ++--
erts/emulator/internal_doc/GarbageCollection.md | 4 ++--
erts/emulator/internal_doc/PTables.md | 8 ++++----
erts/emulator/internal_doc/PortSignals.md | 4 ++--
erts/emulator/internal_doc/SuperCarrier.md | 14 +++++++-------
erts/emulator/internal_doc/ThreadProgress.md | 6 +++---
erts/emulator/internal_doc/Tracing.md | 4 ++--
erts/emulator/internal_doc/beam_makeops.md | 16 ++++++++--------
erts/emulator/internal_doc/dec.erl | 2 +-
11 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/erts/emulator/internal_doc/CodeLoading.md b/erts/emulator/internal_doc/CodeLoading.md
index cfdc1bf30a..fa5bba0643 100644
--- a/erts/emulator/internal_doc/CodeLoading.md
+++ b/erts/emulator/internal_doc/CodeLoading.md
@@ -56,7 +56,7 @@ different modules and returns a "magic binary" containing the internal
state of each prepared module. Function `finish_loading` could take a
list of such states and do the finishing of all of them in one go.
-Currenlty we use the legacy BIF `erlang:load_module` which is now
+Currently we use the legacy BIF `erlang:load_module` which is now
implemented in Erlang by calling the above two functions in
sequence. Function `finish_loading` is limited to only accepts a list
with one module state as we do not yet use the multi module loading
diff --git a/erts/emulator/internal_doc/DelayedDealloc.md b/erts/emulator/internal_doc/DelayedDealloc.md
index 4b7c774141..8a86a70b10 100644
--- a/erts/emulator/internal_doc/DelayedDealloc.md
+++ b/erts/emulator/internal_doc/DelayedDealloc.md
@@ -89,7 +89,7 @@ same location in memory.
The head contains pointers to begining of the list (`head.first`), and
to the first block which other threads may refer to
-(`head.unref_end`). Blocks between these pointers are only refered to
+(`head.unref_end`). Blocks between these pointers are only referred to
by the head part of the data structure which is only used by the
thread owning the allocator instance. When these two pointers are not
equal the thread owning the allocator instance deallocate block after
@@ -137,7 +137,7 @@ If no new memory blocks are inserted into the list, it should
eventually be emptied. All pointers to the list however expect to
always point to something. This is solved by inserting an empty
"marker" element, which only has to purpose of being there in the
-absense of other elements. That is when the list is empty it only
+absence of other elements. That is when the list is empty it only
contains this "marker" element.
### Contention ###
diff --git a/erts/emulator/internal_doc/PTables.md b/erts/emulator/internal_doc/PTables.md
index ef61963a40..6b316eaa7e 100644
--- a/erts/emulator/internal_doc/PTables.md
+++ b/erts/emulator/internal_doc/PTables.md
@@ -113,7 +113,7 @@ the "thread progress" functionality in order to determine when it is
safe to deallocate the process structure. We'll get back to this when
describing deletion in the table.
-Using this new lookup approach we wont modify any memory at all which
+Using this new lookup approach we won't modify any memory at all which
is important. A lookup conceptually only read memory, now this is true
in the implementation also which is important from a scalability
perspective. The previous implementation modified the cache line
@@ -282,7 +282,7 @@ single cache line containing the state of the rwlock even in the case
we are only read locking. Instead of using such an rwlock, we have our
own implementation of reader optimized rwlocks which keeps track of
reader threads in separate thread specific cache lines. This in order
-to avoid contention on a singe cache line. As long as we only do read
+to avoid contention on a single cache line. As long as we only do read
lock operations, threads only need to read a global cache line and
modify its own cache line, and by this minimize communication between
involved processors. The iterating BIFs are normally very infrequently
@@ -299,7 +299,7 @@ threads modify the table at the same time as we are trying to find the
slot. The easy fix is to abort the operation if an empty slot could
not be found in a finite number operation, and then restart the
operation under a write lock. This will be implemented in next
-release, but furter work should be made trying to find a better
+release, but further work should be made trying to find a better
solution.
This and also previous implementation do not work well when the table
@@ -320,7 +320,7 @@ not require exclusive access to the table while reading a sequence of
slots. In principle this should be rather easy, the code can handle
sequences of variable sizes, so shrinking the sequence size of slots
to one would solv the problem. This will, however, need some tweeks
-and modifications of not trival code, but is something that should be
+and modifications of not trivial code, but is something that should be
looked at in the future.
By increasing the size of identifiers, at least on 64-bit machines
diff --git a/erts/emulator/internal_doc/PortSignals.md b/erts/emulator/internal_doc/PortSignals.md
index 8782ae4e17..f2490152ca 100644
--- a/erts/emulator/internal_doc/PortSignals.md
+++ b/erts/emulator/internal_doc/PortSignals.md
@@ -108,7 +108,7 @@ and a private, lock free, queue like, task data structure. This "semi
locked" approach is similar to how the message boxes of processes are
managed. The lock is port specific and only used for protection of
port tasks, so the run queue lock is now needed in more or less the
-same way for ports as for processes. This ensures that we wont see an
+same way for ports as for processes. This ensures that we won't see an
increased lock contention on run queue locks due to this rewrite of
the port functionality.
@@ -211,7 +211,7 @@ consuming, and did not really depend on the port. That is we would
like to do this without having the port lock locked.
In order to improve this, state information was re-organized in the
-port structer, so that we can access it using atomic memory
+port structure, so that we can access it using atomic memory
operations. This together with the new port table implementation,
enabled us to lookup the port and inspect the state before acquiring
the port lock, which in turn made it possible to perform preparations
diff --git a/erts/emulator/internal_doc/SuperCarrier.md b/erts/emulator/internal_doc/SuperCarrier.md
index f52c6613d5..55ac5a67af 100644
--- a/erts/emulator/internal_doc/SuperCarrier.md
+++ b/erts/emulator/internal_doc/SuperCarrier.md
@@ -12,7 +12,7 @@ Problem
-------
The initial motivation for this feature was customers asking for a way
-to pre-allocate physcial memory at VM start for it to use.
+to pre-allocate physical memory at VM start for it to use.
Other problems were different experienced limitations of the OS
implementation of mmap:
@@ -29,7 +29,7 @@ fragmentation increased.
Solution
--------
-Allocate one large continious area of address space at VM start and
+Allocate one large continuous area of address space at VM start and
then use that area to satisfy our dynamic memory need during
runtime. In other words: implement our own mmap.
@@ -70,7 +70,7 @@ name suggest that it can be viewed as our own mmap implementation.
A super carrier needs to satisfy two slightly different kinds of
allocation requests; multi block carriers (MBC) and single block
-carriers (SBC). They are both rather large blocks of continious
+carriers (SBC). They are both rather large blocks of continuous
memory, but MBCs and SBCs have different demands on alignment and
size.
@@ -79,13 +79,13 @@ alignment.
MBCs are more restricted. They can only have a number of fixed
sizes that are powers of 2. The start address need to have a very
-large aligment (currently 256 kb, called "super alignment"). This is a
+large alignment (currently 256 kb, called "super alignment"). This is a
design choice that allows very low overhead per allocated block in the
MBC.
To reduce fragmentation within the super carrier, it is good to keep SBCs
and MBCs apart. MBCs with their uniform alignment and sizes can be
-packed very efficiently together. SBCs without demand for aligment can
+packed very efficiently together. SBCs without demand for alignment can
also be allocated quite efficiently together. But mixing them can lead
to a lot of memory wasted when we need to create large holes of
padding to the next alignment limit.
@@ -102,9 +102,9 @@ The MBC area is called *sa* as in super aligned and the SBC area is
called **sua** as in super un-aligned.
Note that the "super" in super alignment and the "super" in super
-carrier has nothing to do with each other. We could have choosen
+carrier has nothing to do with each other. We could have chosen
another naming to avoid confusion, such as "meta" carrier or "giant"
-aligment.
+alignment.
+-------+ <---- sua.top
| sua |
diff --git a/erts/emulator/internal_doc/ThreadProgress.md b/erts/emulator/internal_doc/ThreadProgress.md
index 03a802f904..a48b250104 100644
--- a/erts/emulator/internal_doc/ThreadProgress.md
+++ b/erts/emulator/internal_doc/ThreadProgress.md
@@ -78,7 +78,7 @@ thread progress operation has been initiated, and at least once
ordered using communication via memory which makes it possible to draw
conclusion about the memory state after the thread progress operation
has completed. Lets call the progress made from initiation to
-comletion for "thread progress".
+completion for "thread progress".
Assuming that the thread progress functionality is efficient, a lot of
algorithms can both be simplified and made more efficient than using
@@ -120,7 +120,7 @@ communication.
We also want threads to be able to determine when thread progress has
been made relatively fast. That is we need to have some balance
-between comunication overhead and time to complete the operation.
+between communication overhead and time to complete the operation.
### API ###
@@ -222,7 +222,7 @@ current global value plus one at the time when we call
confirmed global value plus two at this time.
The above described implementation more or less minimizes the
-comunication needed before we can increment the global counter. The
+communication needed before we can increment the global counter. The
amount of communication in the system due to the thread progress
functionality however also depend on the frequency with which managed
threads call `erts_thr_progress_update()`. Today each scheduler thread
diff --git a/erts/emulator/internal_doc/Tracing.md b/erts/emulator/internal_doc/Tracing.md
index d81739c7cb..f0182daad8 100644
--- a/erts/emulator/internal_doc/Tracing.md
+++ b/erts/emulator/internal_doc/Tracing.md
@@ -106,7 +106,7 @@ instantaneously without the need of external function calls.
The choosen solution is instead for tracing to use the technique of
replication applied on the data structures for breakpoints. Two
-generations of breakpoints are kept and indentified by index of 0 and
+generations of breakpoints are kept and identified by index of 0 and
1. The global atomic variables `erts_active_bp_index` will determine
which generation of breakpoints running code will use.
@@ -236,7 +236,7 @@ value of `erts_active_bp_index` at different times as it is read
without any memory barrier. But this is the best we can do without
more expensive thread synchronization.
-The waiting in step 8 is to make sure we dont't restore the original
+The waiting in step 8 is to make sure we don't restore the original
bream instructions for disabled breakpoints until we know that no
thread is still accessing the old enabled part of a disabled
breakpoint.
diff --git a/erts/emulator/internal_doc/dec.erl b/erts/emulator/internal_doc/dec.erl
index 8ce83fa402..52ab42ebc0 100644
--- a/erts/emulator/internal_doc/dec.erl
+++ b/erts/emulator/internal_doc/dec.erl
@@ -24,7 +24,7 @@
%% The C header is generated from a text file containing tuples in the
%% following format:
%% {RevList,Translation}
-%% Where 'RevList' is a reversed list of the denormalized repressentation of
+%% Where 'RevList' is a reversed list of the denormalized representation of
%% the character 'Translation'. An example would be the swedish character
%% 'รถ', which would be represented in the file as:
%% {[776,111],246}, as the denormalized representation of codepoint 246
--
2.31.1
