| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
The BIFs prepare_loading/2 and finish_loading/1 have been
designed to allow fast loading in parallel of many modules.
Because of the complications with on_load functions,
the initial implementation of finish_loading/1 only allowed
a single element in the list of prepared modules.
finish_loading/1 does not suspend other processes, but it must wait
for all schedulers to pass a write barrier ("thread progress"). The
time for all schedulers to pass the write barrier is highly variable,
depending on what kind of code they are executing. Therefore, allowing
finish_loading/1 to finish the loading for more than one module before
passing the write barrier could potentially be much faster than
calling finish_loading/1 multiple times.
The test case many/1 run on my computer shows that with "heavy load",
finish loading of 100 modules in parallel is almost 50 times faster
than loading them sequentially. With "light load", the gain is still
almost 10 times.
Here follows an actual sample of the output from the test case on
my computer (an 2012 iMac):
Light load
==========
Sequential: 22361 µs
Parallel: 2586 µs
Ratio: 9
Heavy load
==========
Sequential: 254512 µs
Parallel: 5246 µs
Ratio: 49
|
|
|
|
|
|
This simplified debugging on OSE and also limits the number of ppdata
keys that are created when beam is restarted.
|
|
|
|
The concept of code_write_permission is used by tracing as well
and is not specific to code_ix.
|
|
Make sure that the the currently running thread has the lock,
not only that that some thread has the lock.
|
|
"is_blocking" always returns true on non-smp
|
|
Rename lock_code_ix as seize_code_write_permission. Don't want to call
it a "lock" as it can be held between schedulings and different threads
and is not managed by lock checker.
Rename "activate" staging as "commit" staging. Why not be consistent
and use git terminology all the way.
|
|
Make for simpler code when we just can block threads and continue
without having to release code_ix lock and repeat code lookups to
avoid race.
|
|
Renamed it export_staging_lock and made change it to ordinary mutex.
|
|
Activation of staged code is scheduled for a later moment when
all schedulers have done a full memory barrier. This allow
them to read active code index while executing without any
memory barriers at all.
|
|
This will prevent blocking entrire schedulers in the rare case when
several processes are racing to load/upgrade/delete/purge code.
|
|
Move implementation from beam_load into new file code_ix.c and module.c
and make some function inline.
|
