| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
ASSERT(code_writing_process != c_p);
The assert was actually harmless and could be removed as one solution.
But I think it's better to keep it as a way to catch bugs that would
otherwise lead to horrible deadlocks if a thread "forgets" to call
erts_release_code_write_permission().
As a result erts_release_code_write_permission() must be called BEFORE
resuming the suspended process.
|
|
|
|
The concept of code_write_permission is used by tracing as well
and is not specific to code_ix.
|
|
Simplify by removing the support of abort_staging after end_staging.
|
|
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.
|
|
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.
|
|
|
|
Staging is a better and more general name as does not necessary need
to involve code loading (can be deletion, tracing, etc).
|
|
Implemented some code_ix locks
and commented calls to erts_smp_thr_progress_block()
|
|
|
|
Still blocking code loading
|
