aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/code_ix.h
AgeCommit message (Collapse)Author
2017-10-01Refactor macros for accessing Beam instructionsBjörn Gustavsson
The BeamOp() macro in erl_vm.h is clumsy to use. All users cast the return value to BeamInstr. Define new macros that are easier to use. In the future, we might want to pack an operand into the same word as the pointer to the instruction, so we will define two macros. BeamIsOpCode() is used to rewrite code like this: if (Instr == (BeamInstr) BeamOp(op_i_func_info_IaaI) { ... } to: if (BeamIsOpCode(Instr, op_i_func_info_IaaI)) { ... } BeamOpCodeAddr(op_apply_bif) is used when we need the address for an instruction. Also elimiminate the global variables em_* in beam_emu.c. They are not really needed. Use the BeamOpCodeAddr() macro instead.
2017-07-17erts: Replace usage of all erts_smp prefixes to just ertsLukas Larsson
2017-05-04Update copyright yearRaimo Niskanen
2017-04-04erts: Refactor ErtsCodeInfo.nativeSverker Eriksson
into union with actual usage types.
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-06-18Change license text to APLv2Bruce Yinhe
2013-02-22Update copyright yearsBjörn-Egil Dahlberg
2013-01-28erts: Fix ASSERT crash in erts_try_seize_code_write_permissionSverker Eriksson
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.
2012-11-28Fix various comment typos for R16Tuncer Ayaz
2012-08-31erts: Refactor naming regarding code_write_permissionSverker Eriksson
The concept of code_write_permission is used by tracing as well and is not specific to code_ix.
2012-03-07erts: Fix assert failure when code_server exits "during" commitSverker Eriksson
Simplify by removing the support of abort_staging after end_staging.
2012-02-23erts: Refactor code loading with renamingSverker Eriksson
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.
2012-02-23erts: Switch order between code_ix lock and thread blockingSverker Eriksson
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.
2012-02-21erts: Activate staged code in a thread safe waySverker Eriksson
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.
2012-02-21erts: Suspend processes waiting for code_ix lockSverker Eriksson
This will prevent blocking entrire schedulers in the rare case when several processes are racing to load/upgrade/delete/purge code.
2012-02-21erts: Refactor code_ixSverker Eriksson
Move implementation from beam_load into new file code_ix.c and module.c and make some function inline.
2012-02-21erts: Document code_ix interfaceSverker 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-21First try at non-blocking code loading!Sverker Eriksson
Implemented some code_ix locks and commented calls to erts_smp_thr_progress_block()
2012-02-21erts: Multiple module tables using code_ixSverker Eriksson
2012-02-21erts: Multiple export tab's using code_ixSverker Eriksson
Still blocking code loading