aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/bif.tab
AgeCommit message (Collapse)Author
2019-02-14Add persistent_term:get(Key, DefaultValue)Björn Gustavsson
https://bugs.erlang.org/browse/ERL-843
2019-01-10Implement integer_to_list/2 and integer_to_binary/2 as CIFsStanislav Mayorov
This makes them roughly as fast as integer_to_list/1 and integer_to_binary/1.
2019-01-07Spawn prim_file helper as a system processJohn Högberg
2018-11-21erts: Add counters:put/3Sverker Eriksson
2018-11-15erts: Add new module 'counters'Sverker Eriksson
2018-11-15erts: Add new module 'atomics'Sverker Eriksson
2018-11-06Add a persistent term storageBjörn Gustavsson
Persistent terms are useful for storing Erlang terms that are never or infrequently updated. They have the following advantages: * Constant time access. A persistent term is not copied when it is looked up. The constant factor is lower than for ETS, and no locks are taken when looking up a term. * Persistent terms are not copied in garbage collections. * There is only ever one copy of a persistent term (until it is deleted). That makes them useful for storing configuration data that needs to be easily accessible by all processes. Persistent terms have the following drawbacks: * Updates are expensive. The hash table holding the keys for the persistent terms are updated whenever a persistent term is added, updated or deleted. * Updating or deleting a persistent term triggers a "global GC", which will schedule a heap scan of all processes to search the heap of all processes for the deleted term. If a process still holds a reference to the deleted term, the process will be garbage collected and the term copied to the heap of the process. This global GC can make the system less responsive for some time. Three BIFs (implemented in C in the emulator) is the entire interface to the persistent term functionality: * put(Key, Value) to store a persistent term. * get(Key) to look up a persistent term. * erase(Key) to delete a persistent term. There are also two additional BIFs to obtain information about persistent terms: * info() to return a map with information about persistent terms. * get() to return a list of a {Key,Value} tuples for all persistent terms. (The values are not copied.)
2018-05-18Merge branch 'sverker/ets-delete_all_objects-trap/OTP-15078'Sverker Eriksson
* sverker/ets-delete_all_objects-trap/OTP-15078: erts: Rename untrapping db_free_*empty*_table erts: Make ets:delete_all_objects yield on fixed table erts: Optimize ets delete all in fixed table erts: Refactor ets select iteration code erts: Cleanup ets code erts: Optimize ets hash object deallocactions erts: Refactor pseudo deleted ets objects erts: Make atomic ets:delete_all_objects yield erts: Fix reduction bump for ets:delete/1
2018-05-16Replace previous suspend in setnode/3Rickard Green
2018-05-16New process suspend implementation based on async signalingRickard Green
2018-05-08erts: Make atomic ets:delete_all_objects yieldSverker Eriksson
by using a cooperative strategy that will make any process accessing the table execute delelete_all_objects_continue until the table is empty. This is not an optimal solution as concurrent threads will still block on the table lock, but at least thread progress is made.
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-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-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-03-22Fix signal order for is_process_aliveRickard Green
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-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-02-26Replace binary:bin_to_list CIF implementation with binary_to_listJohn Högberg
binary:bin_to_list had a poor implementation that resulted in excessive garbage collection. binary_to_list is almost identical and has a generally better implementation, so I've replaced binary:bin_to_list's CIF with a thin wrapper around binary_to_list. Granted, binary_to_list has a deprecated indexing scheme, but we're unlikely to ever remote it entirely and it's somewhat easy to move it to the 'binary' module later on.
2018-02-22Add ets:whereis/1 for resolving table names -> tid()John Högberg
2018-01-08Merge branch 'john/erts/putenv-thread-safety/OTP-14666'John Högberg
2018-01-03Replace the libc environment with a thread-safe emulationJohn Högberg
putenv(3) and friends aren't thread-safe regardless of how you slice it; a global lock around all environment operations (like before) keeps things safe as far as our own operations go, but we have absolutely no control over what libc or a library dragged in by a driver/NIF does -- they're free to call getenv(3) or putenv(3) without honoring our lock. This commit solves this by setting up an "emulated" environment which can't be touched without going through our interfaces. Third-party libraries can still shoot themselves in the foot but benign uses of os:putenv/2 will no longer risk crashing the emulator.
2017-12-19Redirect system_flag(scheduler_wall_time,_) to kernel_refcRickard Green
2017-11-20Merge branch 'lukas/stdlib/maps_iterators/OTP-14012'Lukas Larsson
* lukas/stdlib/maps_iterators/OTP-14012: erts: Limit size of first iterator for hashmaps Update primary bootstrap Update preloaded modules erts: Remove erts_internal:maps_to_list/2 stdlib: Make io_lib and io_lib_pretty use maps iterator erts: Implement batching maps:iterator erts: Implement maps path iterator erts: Implement map iterator using a stack stdlib: Introduce maps iterator API Conflicts: bootstrap/lib/stdlib/ebin/io_lib.beam bootstrap/lib/stdlib/ebin/io_lib_pretty.beam erts/emulator/beam/bif.tab erts/preloaded/ebin/erlang.beam erts/preloaded/ebin/erts_internal.beam erts/preloaded/ebin/zlib.beam
2017-11-20erts: Remove erts_internal:maps_to_list/2Lukas Larsson
This function is no longer needed as maps:iterator has now been implemented.
2017-11-20erts: Implement batching maps:iteratorLukas Larsson
This iterator implementation fetches multiple elements to iterate over in one call to erts_internal:maps_next instead of one at a time. This means that the memory usage will go up for the iterator as we are buffering elements, but the usage is still bounded. In this implementation the max memory usage is 1000 words. Using this approach makes the iterator as fast as using maps:to_list, so maps:iterator/2 has been removed.
2017-11-15Move new|abort_connection_id to erts_internalSverker Eriksson
and drop _id suffix.
2017-11-15Remove obsolete erlang:dlink/1, dunlink/1 and dist_exit/3Sverker Eriksson
2017-11-15erts: Introduce asynchronous auto-connectSverker Eriksson
2017-10-13erts: Implement maps path iteratorLukas Larsson
2017-10-13erts: Implement map iterator using a stackLukas Larsson
This version does not work great as the subtrees created are not proper hash maps. Also it is not all that performant as the extra allocations to keep the stack there is expensive.
2017-09-06Merge branch 'maint' into john/erts/merge-zlib-and-vector-qJohn Högberg
2017-09-05erts: Add erlang:iolist_to_iovecLukas Larsson
OTP-14520
2017-08-28Merge branch 'rickard/dist/OTP-14459' into rickard/dist/master/OTP-14459Rickard Green
Conflicts: erts/emulator/beam/bif.c erts/emulator/beam/dist.c erts/emulator/beam/dist.h erts/emulator/beam/erl_bif_info.c erts/emulator/beam/erl_node_tables.c erts/emulator/beam/erl_node_tables.h erts/emulator/beam/external.c
2017-08-28Support for distribution controller processesRickard Green
2017-07-06Break erts_debug:lock_counters/1 into separate BIFsJohn Högberg
2017-05-04Update copyright yearRaimo Niskanen
2017-04-25Merge branch 'lukas/erts/list_to_port/OTP-14348'Lukas Larsson
* lukas/erts/list_to_port/OTP-14348: erts: Add erlang:list_to_port/1 debug bif erts: Auto-import port_to_list for consistency erts: Polish off erlang:list_to_ref/1
2017-04-25erts: Add erlang:list_to_port/1 debug bifLukas Larsson
2017-04-24Handle chardata in string:to_float and string:to_listDan Gudmundsson
2017-04-18Merge pull request #1412 from manuel-rubio/manuel-rubio/add-re-versionRickard Green
Add re:version/0 OTP-14347
2017-03-31Add re:version/0Manuel Rubio
2017-03-22ETS: Allow for matchspec-based replacementGuilherme Andrade
2017-03-22Merge branch 'sverker/ets-table-identifiers/OTP-14094'Sverker Eriksson
* sverker/ets-table-identifiers: observer: Polish crashdump viewer for ETS observer: Polish Table Viewer tab stdlib: Remove ets_SUITE:memory_check_summary erts: Improve reduction count during table cleanup erts: Cleanup table status bits erts: Remove now redundant 'id' from DbTableCommon erts: Remove meta_main_tab erts: Pass tid argument down to trapping functions erts: Print table id as ref in crashdump and break menu erts: Replace meta_pid_to{_fixed}_tab with linked lists erts: Correct erl_rbtree comments about yielding erts: Add ERTS_RBT_YIELD_STAT_INIT to erl_rbtree Fix node_container_SUITE list_to_ref/1 Implement ets:all() using scheduler specific data Rename fixation count in ets table to avoid confusion Introduce references as table identifiers
2017-03-22list_to_ref/1Rickard Green
2017-03-02Implement ets:all() using scheduler specific dataRickard Green
2017-02-23erts: Introduce erts_internal:maps_to_list/2Björn-Egil Dahlberg
2017-02-03Merge branch 'egil/20/erts/signal-service/OTP-14186'Björn-Egil Dahlberg
* egil/20/erts/signal-service/OTP-14186: kernel: Document signal server erts: Use os module instead of erts_internal for set_signal/2 erts: Do not handle SIGILL erts: Fix thread suspend in crashdump erts: Do not enable SIGINT erts: Use generic signal handler erts: Add OS signal tests erts: Handle SIGUSR1 via signal service instead erts: Handle SIGTERM via signal service instead kernel: Add gen_event signal server and default handler erts: Add SIGHUP signal handler erts: Remove whitespace errors Conflicts: erts/emulator/beam/bif.tab
2017-02-02erts: Use os module instead of erts_internal for set_signal/2Björn-Egil Dahlberg
* Add specs * Change return signature to 'ok' instead of 'true'
2017-02-02erts: Use generic signal handlerBjörn-Egil Dahlberg