| 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
|
|
to use real C struct with correct types
|
|
to use a real C struct instead of array.
|
|
|
|
Symptom: VM on OSX (darwin11.4.2) with +Meamin running sasl tests,
crashing when init:reboot() does erlang:purge_module(installer).
Problem: Off-by-one bug in beam_ranges:find_range, returning the wrong
range if the 'end' of one module is the 'start' of the next. This is only
possible if using sys_alloc (+Meamin) as our own allocators always put
block headers between allocated payload data.
|
|
|
|
Staging is a better and more general name as does not necessary need
to involve code loading (can be deletion, tracing, etc).
|
|
|
|
Having the entire implementation of range handling (address table)
in one source file will help when we'll need to update the ranges
without stopping all schedulers in the next commit.
|
