aboutsummaryrefslogtreecommitdiffstats
path: root/erts/preloaded
AgeCommit message (Collapse)Author
2018-06-20Update system_info doc to include ets_countArtur Cygan
2018-06-18Update copyright yearHenrik Nord
2018-06-18Update preloaded modulesHenrik Nord
2018-06-04Merge branch 'sverker/erlang-memory-fix'Sverker Eriksson
* sverker/erlang-memory-fix: erts: Purge unused allocation types erts: Fix erlang:memory for 'processes' and 'processes_used'
2018-05-29erts: Improve contracts of zlibHans Bolinder
2018-05-28erts: Improve a contractHans Bolinder
2018-05-23Update preloadedSiri Hansen
2018-05-23Use system_time instead of monotonic_time as timestamp in loggerSiri Hansen
2018-05-22erts: Fix erlang:memory for 'processes' and 'processes_used'Sverker Eriksson
to include links and monitors which were lost at 4bc282d812cc2c49aa3e2d073e96c720f16aa270 where these fix_alloc types changed names.
2018-05-16Replace previous suspend in setnode/3Rickard Green
2018-05-16New process suspend implementation based on async signalingRickard Green
2018-05-07Update preloaded modulesBjörn Gustavsson
2018-05-07Merge pull request #1802 from michalmuskala/map-is-key-bifBjörn Gustavsson
Introduce is_map_key/2 guard BIF OTP-15037
2018-04-29Introduce is_map_key/2 guard BIFMichał Muskała
This complements the `map_get/2` guard BIF introduced in #1784. Rationale. `map_get/2` allows accessing map fields in guards, but it might be problematic in more complex guard expressions, for example: foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ... The `is_list/1` part of the guard could never succeed since the `map_get/2` guard would fail the whole guard expression. In this situation, this could be solved by using `;` instead of `or` to separate the guards, but it is not possible in every case. To solve this situation, this PR proposes a `is_map_key/2` guard that allows to check if a map has key inside a guard before trying to access that key. When combined with `is_map/1` this allows to construct a purely boolean guard expression testing a value of a key in a map. Implementation. Given the use case motivating the introduction of this function, the PR contains compiler optimisations that produce optimial code for the following guard expression: foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok; foo(_) -> error. Given all three tests share the failure label, the `is_map_key/2` and `is_map/2` tests are optimised away. As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
2018-04-26Don't kill logger process until all other processes are deadSiri Hansen
2018-04-26Remove error_logger process and add logger processSiri Hansen
2018-04-25Update preloaded modulesBjörn Gustavsson
2018-04-25Merge branch 'map-get-bif' of git://github.com/michalmuskala/otpBjörn Gustavsson
* 'map-get-bif' of git://github.com/michalmuskala/otp: Introduce map_get guard-safe function OTP-15037
2018-04-24Merge pull request #1790 from jhogberg/john/erts/more-alloc-info/OTP-14961John Högberg
Improve memory instrumentation OTP-15024 OTP-14961
2018-04-24Introduce map_get guard-safe functionMichał Muskała
Rationale Today all compound data types except for maps can be deconstructed in guards. For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are completely opaque to guards. This means matching on maps can't be abstracted into macros, which is often done with repetitive guards. It also means that maps have to be always selected whole from ETS tables, even when only one field would be enough, which creates a potential efficiency issue. This PR introduces an `erlang:map_get/2` guard-safe function that allows extracting a map field in guard. An alternative to this function would be to introduce the syntax for extracting a value from a map that was planned in the original EEP: `Map#{Key}`. Even outside of guards, since this function is a guard-BIF it is more efficient than using `maps:get/2` (since it does not need to set up the stack), and more convenient from pattern matching on the map (compare: `#{key := Value} = Map, Value` to `map_get(key, Map)`). Performance considerations A common concern against adding this function is the notion that "guards have to be fast" and ideally execute in constant time. While there are some counterexamples (`length/1`), what is more important is the fact that adding those functions does not change in any way the time complexity of pattern matching - it's already possible to match on map fields today directly in patterns - adding this ability to guards will niether slow down or speed up the execution, it will only make certain programs more convenient to write. This first version is very naive and does not perform any optimizations.
2018-04-23erts: Rewrite memory instrumentationJohn Högberg
This commit replaces the old memory instrumentation with a new implementation that scans carriers instead of wrapping erts_alloc/erts_free. The old implementation could not extract information without halting the emulator, had considerable runtime overhead, and the memory maps it produced were noisy and lacked critical information. Since the new implementation walks through existing data structures there's no longer a need to start the emulator with special flags to get information about carrier utilization/fragmentation. Memory fragmentation is also easier to diagnose as it's presented on a per-carrier basis which eliminates the need to account for "holes" between mmap segments. To help track allocations, each allocation can now be tagged with what it is and who allocated it at the cost of one extra word per allocation. This is controlled on a per-allocator basis with the +M<S>atags option, and is enabled by default for binary_alloc and driver_alloc (which is also used by NIFs).
2018-04-16Deprecate erlang:get_stacktrace/0Björn Gustavsson
2018-04-10erts: Flush messages before doing init restartLukas Larsson
If messages are not flushed they would cause problems when the system is booting. For instance module load requests would be issued before the prim loader has been launched.
2018-03-23Merge branch 'rickard/signals/OTP-14589'Rickard Green
* rickard/signals/OTP-14589: Fix VM probes compilation Fix lock counting Fix signal order for is_process_alive Fix signal handling priority elevation
2018-03-23Merge branch 'john/erts/list-installed-nifs/OTP-14965'John Högberg
* john/erts/list-installed-nifs/OTP-14965: Add an option to ?MODULE:module_info/1 for listing NIFs Fix a misleading comment
2018-03-22Fix signal order for is_process_aliveRickard Green
2018-03-22Merge branch 'bjorn/erts/eliminate-get_stacktrace'Björn Gustavsson
* bjorn/erts/eliminate-get_stacktrace: Eliminate use of erlang:get_stacktrace/0 in preloaded modules
2018-03-21Add an option to ?MODULE:module_info/1 for listing NIFsJohn Högberg
2018-03-21Merge pull request #1740 from rickard-green/rickard/signals/OTP-14589Rickard Green
Implementation of true asynchronous signaling between processes
2018-03-21Implementation of true asynchronous signaling between processesRickard Green
Communication between Erlang processes has conceptually always been performed through asynchronous signaling. The runtime system implementation has however previously preformed most operation synchronously. In a system with only one true thread of execution, this is not problematic (often the opposite). In a system with multiple threads of execution (as current runtime system implementation with SMP support) it becomes problematic. This since it often involves locking of structures when updating them which in turn cause resource contention. Utilizing true asynchronous communication often avoids these resource contention issues. The case that triggered this change was contention on the link lock due to frequent updates of the monitor trees during communication with a frequently used server. The signal order delivery guarantees of the language makes it hard to change the implementation of only some signals to use true asynchronous signaling. Therefore the implementations of (almost) all signals have been changed. Currently the following signals have been implemented as true asynchronous signals: - Message signals - Exit signals - Monitor signals - Demonitor signals - Monitor triggered signals (DOWN, CHANGE, etc) - Link signals - Unlink signals - Group leader signals All of the above already defined as asynchronous signals in the language. The implementation of messages signals was quite asynchronous to begin with, but had quite strict delivery constraints due to the ordering guarantees of signals between a pair of processes. The previously used message queue partitioned into two halves has been replaced by a more general signal queue partitioned into three parts that service all kinds of signals. More details regarding the signal queue can be found in comments in the erl_proc_sig_queue.h file. The monitor and link implementations have also been completely replaced in order to fit the new asynchronous signaling implementation as good as possible. More details regarding the new monitor and link implementations can be found in the erl_monitor_link.h file.
2018-03-21Eliminate use of erlang:get_stacktrace/0 in preloaded modulesBjörn Gustavsson
2018-03-19Fix file:change_group/change_ownerJohn Högberg
It wasn't possible to change group/owner separately, and our test suite lacked coverage for that. ERL-589
2018-03-13Merge branch 'sverker/dist-flags-consolidate'Sverker Eriksson
2018-03-02erts,kernel: Add dist_util:strict_order_flags/0Sverker Eriksson
to replace DFLAGS_STRICT_ORDER_DELIVERY and remove that compile time dependency.
2018-03-02erts,kernel: Add erts_internal:get_dflags/0Sverker Eriksson
for kernel to ask erts about distribution flags and keep this info in one place.
2018-03-02erts: Cleanup erlang:system_info docsLukas Larsson
Attempt to make the system_info docs easier to navigate by grouping items of similar themes together in the documentation.
2018-02-20Merge branch 'maint'Sverker Eriksson
2018-02-15kernel: Reject load of module names with slashSverker Eriksson
or backslash on Windows. Purpose: Prevent tricks to get hostile code running.
2018-02-13Merge branch 'maint-20' into maintSverker Eriksson
* maint-20: Updated OTP version Update release notes Update version numbers erts: Add system_flags(erts_alloc,"+M?sbct *") erts: Add age order first fit allocator strategies erts: Refactor erl_ao_firstfit_alloc erts: Add migration options "acnl" and "acfml" kernel: Add os:cmd/2 with max_size option erts: Add more stats for mbcs_pool erts: Fix alloc_SUITE:migration stdlib: Make ets_SUITE memory check try again erts: Improve carrier pool search erts: Improve alloc_SUITE:migration erts: Refactor carrier dealloc migration
2018-02-12Merge 'sverker/maint-20/alloc-n-migration/ERIERL-88'Sverker Eriksson
into 'sverker/master/alloc-n-migration/ERIERL-88'
2018-02-12Merge 'sverker/maint-19/alloc-n-migration/ERIERL-88'Sverker Eriksson
into 'sverker/maint-20/alloc-n-migration/ERIERL-88' OTP-14915 OTP-14916 OTP-14917 OTP-14918
2018-02-12Merge 'sverker/carrier-migration-improvements'Sverker Eriksson
into 'sverker/maint-19/alloc-n-migration/ERIERL-88'
2018-02-12erts: Add system_flags(erts_alloc,"+M?sbct *")Sverker Eriksson
to change sbct limit in runtime for chosen allocator type. With great power comes great responsibility.
2018-02-02Reword docs related to the runtime system modeXavier Noria
The existing wording may be interpreted as saying that embedded mode eager loads all modules. This revision makes clear embedded mode only disables module auto loading. Since I was on it, I have reordered a couple of places to describe interactive first, and then embedded. It feels natural to cover first the default and positive mode (auto loads), and then its negation.
2018-01-15Merge branch 'maint'Sverker Eriksson
2018-01-09erts: Fix term_to_binary/2 specSverker Eriksson
2017-12-20erts: Add more stats for mbcs_poolSverker Eriksson
similar to the ones in OTP-19.2.3.1
2017-12-19Merge branch 'dgud/kernel/refc_sched_wall_time/OTP-11694'Dan Gudmundsson
* dgud/kernel/refc_sched_wall_time/OTP-11694: test: spawn scheduler_wall_time flag holder Turn on scheduler_wall_time in an alive process Redirect system_flag(scheduler_wall_time,_) to kernel_refc kernel: add a resource reference counter
2017-12-19Redirect system_flag(scheduler_wall_time,_) to kernel_refcRickard Green
2017-11-30Reimplement efile_drv as a dirty NIFJohn Högberg
This improves the latency of file operations as dirty schedulers are a bit more eager to run jobs than async threads, and use a single global queue rather than per-thread queues, eliminating the risk of a job stalling behind a long-running job on the same thread while other async threads sit idle. There's no such thing as a free lunch though; the lowered latency comes at the cost of increased busy-waiting which may have an adverse effect on some applications. This behavior can be tweaked with the +sbwt flag, but unfortunately it affects all types of schedulers and not just dirty ones. We plan to add type-specific flags at a later stage. sendfile has been moved to inet_drv to lessen the effect of a nasty race; the cooperation between inet_drv and efile has never been airtight and the socket dying at the wrong time (Regardless of reason) could result in fd aliasing. Moving it to the inet driver makes it impossible to trigger this by closing the socket in the middle of a sendfile operation, while still allowing it to be aborted -- something that can't be done if it stays in the file driver. The race still occurs if the controlling process dies in the short window between dispatching the sendfile operation and the dup(2) call in the driver, but it's much less likely to happen now. A proper fix is in the works. -- Notable functional differences: * The use_threads option for file:sendfile/5 no longer has any effect. * The file-specific DTrace probes have been removed. The same effect can be achieved with normal tracing together with the nif__entry/nif__return probes to track scheduling. -- OTP-14256