From a6593ad961a46fae210d6bf2bd31cc9bc74374eb Mon Sep 17 00:00:00 2001 From: Dmytro Lytovchenko Date: Tue, 26 Mar 2024 18:42:41 +0100 Subject: [PATCH] Minor edits --- .gitignore | 6 +++--- docs/source/eli5-atoms.rst | 4 ++-- docs/source/eli5-efficiency.rst | 6 +++--- docs/source/index.rst | 2 ++ 4 files changed, 10 insertions(+), 8 deletions(-) diff --git a/.gitignore b/.gitignore index f53e4f8..3d3c22f 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,4 @@ -/docs/build/* -/src/* +/src/ *.iml -.idea/* \ No newline at end of file +/.idea/ +/docs/build/ diff --git a/docs/source/eli5-atoms.rst b/docs/source/eli5-atoms.rst index 1029fc5..3733b50 100644 --- a/docs/source/eli5-atoms.rst +++ b/docs/source/eli5-atoms.rst @@ -19,12 +19,12 @@ atoms operations are cheap. BEAM loader routine reads atom values and looks them up in atom table. It replaces atom names with their integer values, tagged as Atom -:ref:`immediate `. Henceforth the code manipulates immediate integer +:ref:`immediate `. Henceforth the code internally manipulates integer values instead of names. These internal values cannot leave the node (over the network or on disk) as integers. This is because another node will have different numeric values -for atoms. Thus when leaving the node atoms are always converted to strings. +for same named atoms. Thus when leaving the node atoms are always converted to strings. This affects BEAM files, external pids, external ports, atoms in Mnesia/DETS and so on. This is the reason why sometimes developers prefer short atom names for database field names — they will appear as strings in database data. diff --git a/docs/source/eli5-efficiency.rst b/docs/source/eli5-efficiency.rst index 8991541..e5c4a10 100644 --- a/docs/source/eli5-efficiency.rst +++ b/docs/source/eli5-efficiency.rst @@ -24,8 +24,8 @@ Here are general rules regarding data copying and performance. Literals (Constants) -------------------- -All Erlang values in your module (literals) are saved in the module file and -then loaded when your module loads. +All Erlang values in your module which are larger than a single machine word are called literals. +Literals are saved in the module file and then loaded when your module loads. These values are stored in special memory area called constant pool and later when you reload your code the garbage collector will move old constants to your process heap (see note below, this has changed in OTP 20.0). @@ -36,7 +36,7 @@ store large binaries in code etc. .. note:: - In Erlang versions prior to 20.0 a constant value will be copied when + In Erlang versions prior to 20.0 a constant value would be copied when crossing process boundary (explained above in "Data Copying"). This has changed in version 20.0 (OTP-13529 in `Release Notes `_ ) diff --git a/docs/source/index.rst b/docs/source/index.rst index 679e05c..a580160 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -8,6 +8,8 @@ knowledge such as VM internals, memory layout, opcodes etc. The project is work in progress, so come back soon! Github repository for pages https://github.com/kvakvs/beam-wisdoms +Knowledge cutoff: OTP 20 + Latest ``````