aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/beam_ranges.c
AgeCommit message (Collapse)Author
2016-10-12erts: Refactor find_function_from_pc to return MFALukas Larsson
2016-10-12erts: Refactor out func_info into structLukas Larsson
This commit adds two new structs to be used to represent erlang code in erts. ErtsCodeInfo is used to describe the i_func_info header that is part of all Export entries and the prelude of each function. This replaces all the BeamInstr * that were previously used to point to these locations. After this change the code should never use BeamInstr * with offsets to figure out different parts of the func_info header. ErtsCodeMFA is a struct that is used to descripe a MFA in code. It is used within ErtsCodeInfo and also in Process->current. All function that previously took Eterm * or BeamInstr * to identify a MFA now use the ErtsCodeMFA or ErtsCodeInfo where appropriate. The code has been tested to work when adding a new field to the ErtsCodeInfo struct, but some updates are needed in ops.tab to make it work.
2016-03-15update copyright-yearHenrik Nord
2016-02-25Allow erlang:finish_loading/1 to load more than one moduleBjörn Gustavsson
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
2015-11-12erts: Refactor line table in loaded beam codeSverker Eriksson
to use real C struct with correct types
2015-11-12erts: Refactor header of loaded beam codeSverker Eriksson
to use a real C struct instead of array.
2015-06-18Change license text to APLv2Bruce Yinhe
2014-10-29erts: Fix bug in beam_rangesSverker Eriksson
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.
2012-02-21erts: Change module range end to be atomicSverker Eriksson
2012-02-21erts: Rename "loader" code_ix as "staging" code_ixSverker Eriksson
Staging is a better and more general name as does not necessary need to involve code loading (can be deletion, tracing, etc).
2012-02-21beam_ranges: Make ranges safe with multi-scheduling activeBjörn Gustavsson
2012-02-21BEAM loader: Break out handling of ranges into beam_ranges.cBjörn Gustavsson
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.