From 9d0638216d35ca0f21c1eea20f8daa3992ac4f71 Mon Sep 17 00:00:00 2001
From: Rickard Green
Date: Tue, 2 Aug 2016 15:58:06 +0200
Subject: Fix purge of code
Ensure that we cannot get any dangling pointers into code that
has been purged. This is done by a two phase purge. At first
phase all fun entries pointing into the code to purge are marked
for purge. All processes trying to call these funs will be suspended
and by this we avoid getting new direct references into the code.
When all processes has been checked, these processes are resumed.
The new purge strategy now also completely ignore the existence of
indirect references to the code (funs). If such exist, they will
cause bad fun exceptions to the caller, but will not prevent a
soft purge or cause a kill of a process having such live references
during a hard purge. This since it is impossible to give any
guarantees that no processes in the system have such indirect
references. Even when the system is completely clean from such
references, new ones can appear via distribution and/or disk.
---
erts/doc/src/erlang.xml | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
(limited to 'erts/doc/src')
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 6289f033b2..a146d4f2b1 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -764,6 +764,29 @@
and the operation was requested
by passing option {allow_gc, false}.
+
+
+ Up until ERTS version 8.*, the check process code operation
+ checks for all types of references to the old code. That is,
+ direct references (e.g. return addresses on the process
+ stack), indirect references (funs in process
+ context), and references to literals in the code.
+
+
+ As of ERTS version 9.0, the check process code operation
+ only checks for direct references to the code. Indirect
+ references via funs will be ignored. If such
+ funs exist and are used after a purge of the old
+ code, an exception will be raised upon usage (same as
+ the case when the fun is received by the process
+ after the purge). Literals will be taken care of (copied)
+ at a later stage. This behavior can as of ERTS version
+ 8.1 be enabled when
+ building OTP,
+ and will automatically be enabled if dirty scheduler
+ support is enabled.
+
+
See also code(3).
Failures:
--
cgit v1.2.3
From 0e04e76df2ea71e2e2e116afef04c497d84b1024 Mon Sep 17 00:00:00 2001
From: Rickard Green
Date: Mon, 8 Aug 2016 17:13:24 +0200
Subject: Perform check_process_code while process is executing dirty
---
erts/doc/src/erl_nif.xml | 16 ----------------
1 file changed, 16 deletions(-)
(limited to 'erts/doc/src')
diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml
index f3921f1922..2a04db0eab 100644
--- a/erts/doc/src/erl_nif.xml
+++ b/erts/doc/src/erl_nif.xml
@@ -462,22 +462,6 @@ ok
heap, and process control block will be delayed until the
dirty NIF has completed.
-
- Currently known issues that are planned to be fixed:
-
- -
-
- Since purging of a module currently might need to garbage
- collect a process in order to determine if it has
- references to the module, a process executing a dirty
- NIF might delay purging for a very long time. Delaying
- a purge operation implies delaying all code
- loading operations which might cause severe problems for
- the system as a whole.
-
-
-
-
--
cgit v1.2.3