otp.git - Mirror of Erlang/OTP repository.

Age	Commit message (Collapse)	Author
2018-11-15	erts: Add new module 'counters'	Sverker Eriksson

2018-11-15	erts: Add new module 'atomics'	Sverker Eriksson

2018-11-06	Add a persistent term storage	Bjö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.)
2016-07-13	erts: Review of documentation changes	Lukas Larsson

2016-07-13	erts: Editorial changes	xsipewe

2016-04-15	erts: Implement tracer modules	Lukas Larsson
	Add the possibility to use modules as trace data receivers. The functions in the module have to be nifs as otherwise complex trace probes will be very hard to handle (complex means trace probes for ports for example). This commit changes the way that the ptab->tracer field works from always being an immediate, to now be NIL if no tracer is present or else be the tuple {TracerModule, TracerState} where TracerModule is an atom that is later used to lookup the appropriate tracer callbacks to call and TracerState is just passed to the tracer callback. The default process and port tracers have been rewritten to use the new API. This commit also changes the order which trace messages are delivered to the potential tracer process. Any enif_send done in a tracer module may be delayed indefinitely because of lock order issues. If a message is delayed any other trace message send from that process is also delayed so that order is preserved for each traced entity. This means that for some trace events (i.e. send/receive) the events may come in an unintuitive order (receive before send) to the trace receiver. Timestamps are taken when the trace message is generated so trace messages from differented processes may arrive with the timestamp out of order. Both the erlang:trace and seq_trace:set_system_tracer accept the new tracer module tracers and also the backwards compatible arguments. OTP-10267
2016-03-15	update copyright-year	Henrik Nord

2015-06-18	Change license text to APLv2	Bruce Yinhe

2013-04-19	Convert XML files to UTF-8	Hans Bolinder

2013-01-25	Update copyright years	Björn-Egil Dahlberg

2012-07-19	erts: Update doc to reflect VxWorks removal	Björn-Egil Dahlberg

2009-11-20	The R13B03 release.OTP_R13B03	Erlang/OTP