aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/ops.tab
AgeCommit message (Collapse)Author
2015-04-27erts: Specialize minus and plus instructionBjörn-Egil Dahlberg
Seen on SSL application where substraction with x registers were prevalent: * i_minus specialization on x registers * i_plus specialization on x registers
2015-04-27erts: Add move2 specialization for common move patternsBjörn-Egil Dahlberg
Common pattern seen in SSL: move y x | move r x -> move2 move r x | move y x -> move2 Common pattern seen in SSL and Compiler: move x r | move x x -> move2
2015-04-24erts: Specialize rem instruction for common caseBjörn-Egil Dahlberg
* i_rem specialization on x registers
2015-04-24erts: Specialize band instruction for common caseBjörn-Egil Dahlberg
* i_band specialization on x registers and constants
2015-04-23erts: Add move window instructionBjörn-Egil Dahlberg
Move an entire region of x registers to the stack. This reduces the dispatch pressure of move instructions. Also introduce a move2 specialization for some common move patterns: move r y | move x y -> move2 : As above, moving regions to the stack move x r | move x y -> move2 : A seemingly common pattern
2015-04-23erts: Add instruction move3 for xy and xxBjörn-Egil Dahlberg
2015-04-23erts: Specialize compare instructionsBjörn-Egil Dahlberg
* i_is_lt for r, x registers and constants * i_is_ge for x registers and constants * i_is_exact_eq for r and x registers
2015-04-13Pre-compute hash values for the general get_map_elements instructionBjörn Gustavsson
See the previous commit for justification and use cases.
2015-04-13Teach the loader to pre-compute the hash value for single-key lookupsBjörn Gustavsson
Let the loader pre-compute the hash value when a single, literal key is matched as in: #{<<"some_key">>:=V} = Map In my measurements, this optimization resulted in a 30 percent speedup for short binary keys. Unfortunately, this optimizization makes no difference for small maps with less than 32 keys, since the hash value is not used. Still, there are the following use cases: * A map used instead of a record with more than 32 entries. I have seen some applications with huge records. * Lookup in JSON dictionaries represented as maps. The hash value will only be used when the map is a hash map (currently, that means at least 32 entries).
2015-04-13Optimize use of i_get_map_element/4Björn Gustavsson
In the i_get_map_element/4 instruction, for literal keys other than atoms, the key would be put into x[0] instead of used directly in the instruction. The reason is that the original implementation of maps only supported atom keys.
2015-04-13Sort maps keys in the loaderBjörn Gustavsson
The map instructions require that the keys in the instructions are sorted (for flatmaps). But that is an implementation detail that should not exposed outside of the BEAM virtual machine. Therefore, make the sorting of the keys the responsibility of the loader and not the compiler. Also note that the sort order for maps with numeric keys or keys with numeric components has changed in OTP 18. That means that code compiled for OTP 17 that operated on maps with map keys might not work in OTP 18 without the sorting in the loader (although it is unlikely to be an issue in practice).
2015-04-13De-optimize the has_map_fields instructionsBjörn Gustavsson
The has_map_fields instruction is infrequently used. Thus there is no need to have the fastest possible implementation; it is better to have an implementation that reduces the code size in the already big process_main() function. We can transform has_map_fields to a get_map_elements instruction, targeting the same unused x[0] register for all keys. That instruction will only be marginally slower than existing implementation.
2015-04-13Fully evaluate is_map/1 for literals at load-timeBjörn Gustavsson
The compiler will only emit is_map/1 instructions with literal argument if optimization is turned off. Therefore, the only reason for this commit is cleanliness.
2015-04-13Remove the fail label operand of the new_map instructionBjörn Gustavsson
The new_map instruction cannot fail, and thus needs no fail label.
2015-04-13Correct transformation of put_map_assoc to new_mapBjörn Gustavsson
A put_map_assoc instruction with an empty source map should be converted to a simpler new_map instruction. The transformation didn't happen because an empty source map is no longer represented as a NIL term (as it was in the beginning before map literals were implemented).
2015-04-13Remove support for put_map_exact without a source mapBjörn Gustavsson
Using the exact operator (':=') is only allowed when an existing map is being updated. Thus the following causes a compilation error: #{k:=v} Therefore there is no need to support the put_map_exact instruction without a source map.
2014-12-05erts: Use linear search for small select_val arraysBjörn-Egil Dahlberg
For searching a key in an array we use linear search in arrays up to 10 elements. Selecting on tuple arity will always use linear search. Instead of using two different instructions we assume selecting on different tuple arities are always few in numbers.
2014-03-17erts: Handle literals in is_map/1Björn-Egil Dahlberg
2014-02-21erts: Maps src instructions can't be literalsBjörn-Egil Dahlberg
Move src to a register if it is a literal.
2014-02-19erts: Introduce new instructions for combined key fetchesBjörn-Egil Dahlberg
2014-02-05erts: Fix Maps for beam_loadBjörn-Egil Dahlberg
Map source may be anything, not only registers.
2014-01-28compiler: Implement different instructions for => and :=Björn Gustavsson
2014-01-28erts: Maps beam-instruction definitionsBjörn Gustavsson
2014-01-28Implement support for maps in the compilerBjörn Gustavsson
To make it possible to build the entire OTP system, also define dummys for the instructions in ops.tab.
2013-11-18Execution of system tasks in context of another processRickard Green
A process requesting a system task to be executed in the context of another process will be notified by a message when the task has executed. This message will be on the form: {RequestType, RequestId, Pid, Result}. A process requesting a system task to be executed can set priority on the system task. The requester typically set the same priority on the task as its own process priority, and by this avoiding priority inversion. A request for execution of a system task is made by calling the statically linked in NIF erts_internal:request_system_task(Pid, Prio, Request). This is an undocumented ERTS internal function that should remain so. It should *only* be called from BIF implementations. Currently defined system tasks are: * garbage_collect * check_process_code Further system tasks can and will be implemented in the future. The erlang:garbage_collect/[1,2] and erlang:check_process_code/[2,3] BIFs are now implemented using system tasks. Both the 'garbage_collect' and the 'check_process_code' operations perform or may perform garbage_collections. By doing these via the system task functionality all garbage collect operations in the system will be performed solely in the context of the process being garbage collected. This makes it possible to later implement functionality for disabling garbage collection of a process over context switches. Newly introduced BIFs: * erlang:garbage_collect/2 - The new second argument is an option list. Introduced option: * {async, RequestId} - making it possible for users to issue asynchronous garbage collect requests. * erlang:check_process_code/3 - The new third argument is an option list. Introduced options: * {async, RequestId} - making it possible for users to issue asynchronous check process code requests. * {allow_gc, boolean()} - making it possible to issue requests that aren't allowed to garbage collect (operation will abort if gc should be needed). These options have been introduced as a preparation for parallelization of check_process_code operations when the code_server is about to purge a module.
2013-02-22Update copyright yearsBjörn-Egil Dahlberg
2013-02-07BEAM loader: Handle element(Pos, not_a_tuple)Björn Gustavsson
The loader failed to load non-optimized BEAM code generated from: element(2, not_a_tuple) Commit ece4c17d2288a3161c995 introduced such code into core_fold_SUITE, leading to core_fold_no_opt_SUITE and core_fold_post_opt_SUITE failing to load.
2012-06-25Don't go to single-scheduler mode when managing breakpointsBjörn Gustavsson
Calls to erlang:set_trace_pattern/3 will no longer block all other schedulers. We will still go to single-scheduler mode when new code is loaded for a module that is traced, or when loading code when there is a default trace pattern set. That is not impossible to fix, but that requires much closer cooperation between tracing BIFs and the loader BIFs.
2012-06-25Change the data structures for breakpointsBjörn Gustavsson
Change the data structures for breakpoints to make it possible (in a future commit) to manage breakpoints without taking down the system to single-scheduling mode. The current "breakpoint wheel" data structure (a circular, double-linked list of breakpoints) was invented before the SMP emulator. To support it in the SMP emulator, there is essentially one breakpoint wheel per scheduler. As more breakpoint types have been added, the implementation has become messy and hard to understand and maintain. Therefore, the time for a rewrite has come. Use one struct to hold all breakpoint data for a breakpoint in a function. Use a flag field to indicate what different type of break actions that are enabled.
2012-03-30Merge branch 'maint'Björn-Egil Dahlberg
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-03-22Merge branch 'maint'Patrik Nyblom
Conflicts: erts/emulator/beam/beam_emu.c erts/emulator/beam/bif.tab erts/preloaded/ebin/prim_file.beam lib/hipe/cerl/erl_bif_types.erl
2012-03-22Rename dyntrace BIFs to more suiting namesPatrik Nyblom
2012-03-22If VM probes are not enabled, short-circuit calls to probe BIFsBjörn Gustavsson
2012-01-11beam_load.c: apply/2 does not need a special caseBjörn Gustavsson
It is wrongly assumed in the BEAM loader that apply/2 is a BIF and must be treated specially. Also make it clearer in ops.tab that apply/3 is a BIF, but apply/2 is not.
2011-10-26Simplify the instructions for calling BIFsBjörn Gustavsson
Taking advantage of the new calling convention for BIFs, we only need one instruction to handle BIFs with any number of arguments. This change eliminates the limit of three arguments for BIFs, but traps are still limited to three arguments.
2011-10-11Simplify transformations of gc_bif[123] instructionsBjörn Gustavsson
Each gc_bif[123] instruction must have both a transformation in ops.tab and special code in gen_guard_bif[123](). Rewrite it to do most of the work in gen_guard_bif[123]().
2011-10-11Refactor 'too_old_compiler' handlingBjörn Gustavsson
In the handling of generic instructions, we used to always test whether the instruction was 'too_old_compiler' and abort loading with a special error message. Refactor the code so that we only do test if we an error has occurred. That will allow us to make the test more expensive in the future, allowing us to customize error messages for certain opcode without any cost in the successful case.
2011-10-11Remove some unnecessary type constraints in transformationsBjörn Gustavsson
We don't need type constraints that essentially are assertions; the wrong type will be detected and loading aborted when no specific instruction can be found.
2011-10-11Get rid of redundant 'try_me_else' and 'fail' instructionsBjörn Gustavsson
If the left part of a transformation will always match, omit the the 'try_me_else' and 'fail' instructions. As part of this optimization, make it an error to have a transformation that can never be reached because of a previous transformation that will always match. (Remove one transformation from ops.tab that was found to be unreachable.)
2011-10-11Remove too_old_compiler handling for very old instruction variantsBjörn Gustavsson
is_list/2 and other test instructions with a zero label was last generated by the v1 BEAM compiler which was last supported in R6B. Since BEAM modules produced by that compiler will be rejected with a nice error message for other reasons (e.g. by the test for the module_info/0,1 functions), retaining those transformations serves no useful purpose.
2011-10-11Remove the special instructions for the hybrid heap emulatorBjörn Gustavsson
The hybrid-heap emulator is broken since R12, so there is no need to keep those instructions.
2011-10-11Remove optimization of 'move R R'Björn Gustavsson
Ancient versions of BEAM compiler could generate move instruction with the same source and destination registers, so the loader would optimize away such instructions.
2011-08-16ops.tab: Remove line instructions before tail-recursive callsBjörn Gustavsson
2011-08-16BEAM loader: Load the line tableBjörn Gustavsson
2011-08-16compiler, emulator: Introduce the line/1 instructionBjörn Gustavsson
Introduce the line/1 instruction in the compiler and the BEAM virtual machine. It will not yet be generated by the compiler and will not actually carry any information.
2011-08-03Fix binary construction with huge literal sizesBjörn Gustavsson
Constructing binaries using the bit syntax with literals sizes that would not fit in an Uint will either cause an emulator crash or the loading to be aborted. Use the new TAG_o tag introduced in the previous commit to make sure that the attempt to create huge binary literals will generate a system_limit exception at run-time.
2011-05-20Update copyright yearsBjörn-Egil Dahlberg
2011-03-29BEAM loader: Simplify handling of the func_info/3 instructionBjörn Gustavsson
For some historical reason, the transformation of a func_info/3 instruction to the internal i_func_info/4 instruction is more involved than it needs to be. Remove the gen_func_info() function in the loader and use a simple transformation.
2011-01-17Introduce a few more variations of the move instructionsBjörn Gustavsson
Frequency counts show that move Const x(1) move Const x(2) are very common.