| Age | Commit message (Collapse) | Author |
|---|
|
The ERTS internal system block functionality has been replaced by
new functionality for blocking the system. The old system block
functionality had contention issues and complexity issues. The
new functionality piggy-backs on thread progress tracking functionality
needed by newly introduced lock-free synchronization in the runtime
system. When the functionality for blocking the system isn't used
there is more or less no overhead at all. This since the functionality
for tracking thread progress is there and needed anyway.
|
|
For cleanliness, store the trap address in p->i instead of in
p->def_arg_reg[3].
|
|
Store arguments for a trap in the X register array to allow
traps to have any number of arguments.
|
|
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.
|
|
The current calling convention for BIFs makes it necessary to
handle each arity specially, since each argument for the BIF
also becomes an argument for the C function implementing the BIF,
which makes it hard to allow BIFs with any number of arguments.
Change the calling convention for BIFs, so that BIF arguments are
passed in an array to the C function implementing the BIF.
|
|
As a preparation for changing the calling convention for
BIFs, make sure that all BIFs use the macros. Also, eliminate
all calls from one BIF to another, since that also breaks
the calling convention abstraction.
|
|
* bjorn/unicode-noncharacters/OTP-9624:
Allow noncharacter code points in unicode encoding and decoding
|
|
The two noncharacter code points 16#FFFE and 16#FFFF were not
allowed to be encoded or decoded using the unicode module or
bit syntax. That causes an inconsistency, since the noncharacters
16#FDD0 to 16#FDEF could be encoded/decoded.
There is two ways to fix that inconsistency.
We have chosen to allow 16#FFFE and 16#FFFF to be encoded and
decoded, because the noncharacters could be useful internally
within an application and it will make encoding and decoding
slightly faster.
Reported-by: Alisdair Sullivan
|
|
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.
|
|
The hybrid-heap emulator is broken since R12, so there is no
need to keep those instructions.
|
|
In the half-word emulator, smp emulator, and non-smp emulator
the X register and float register arrays were allocated in
different ways.
Always allocate the registers and store the pointers to the
allocated register arrays in the scheduler data.
|
|
Put the actual saving of the continuation pointers on the stack
in the new function erts_save_stacktrace() so that it can be reused.
The code is too tricky and complicated to allow it to
become duplicated.
|
|
|
|
As a preparation for providing information about the source
location for an MFA item in an exception stacktrace, refactor
the code that builds the exception stacktrace. Basically we
need two passes over the saved continuation counters: a first
pass to calculate the needed heap space and a second pass to
actually build the stacktrace.
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
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.
|
|
Attempting to construct <<0:((1 bsl 32)-1)>>, the largest bitstring
allowed in a 32 bit emulator, would cause an emulator crash because
of integer overflow.
Fix the problem by using an Uint64 to avoid integer overflow.
Do not attempt to handle construction of <<0:((1 bsl 64)-1>> in
a 64-bit emulator, because that will certainly cause the emulator
to terminate anyway because of insufficient memory.
|
|
* rickard/barriers/OTP-9281:
Silence warnings
Fix build with hipe on amd64
Reduce number of atomic ops
Use 32-bit atomic for port snapshot
Remove pointless erts_ports_alive variable
Ensure quick break
Ensure that all rehashing information are seen when done
Ensure that stack updates are seen when stack is released
Add needed barriers for write_concurrency tables
Homogenize memory barriers on atomics
|
|
|
|
|
|
Conflicts:
erts/vsn.mk
|
|
Fix thread unsafe access to process status field introduced in OTP-9125.
|
|
The status of a process was unnecessarily set to waiting before
the process was enqueued in a run queue. This bug was harmless
up until OTP-R14B01. In OTP-R14B02 erlang:hibernate/3 was fixed
(OTP-9125). After the introduction of OTP-9125, the previously
harmless process status bug sometimes caused erroneous badarg
exceptions from process_info().
|
|
Calling a BIF thaf is called as a function (such as process_info/{1,2})
would leave a non-zero value in c_p->cp, which would lead to
duplicate entries in the stacktrace.
|
|
* pg/fix-hibernate-with-hipe:
Update copyright years
Fix NULL-free bug in hibernate on debug emulator
Fix several bugs related to hibernate/3 and HiPE
Conflicts:
erts/emulator/test/hibernate_SUITE.erl
OTP-9125
|
|
The call_fun() function in the BEAM emulator is supposed to
to put the fun term in the x register following the actual arguments
and environment for the fun. But if the fun is not loaded and
a call to the error_handler:undefined_lambda/3 function is set up,
the x(3) register will not be initialized.
The lack of initialization is very unlikely to cause a problem
in practice, because all of the following things must happen:
1) An unloaded fun must be called (i.e. the fun must have
been received from another node or from a file or dets table).
2) The process must be scheduled out before the call to the
error_handler:undefined_lambda/3 function can take place.
3) The process must be garbage collected before the process
is scheduled in.
4) The x(3) register must contain a stale cons or box pointer
that happens to point into the the heap of the currently
executing process. (Because of the literal pool, the GC will
never copy anything that is outside of the heap.)
I was not able to write a test case that would force an
emulator crash.
|
|
* pan/halfword-tmp-heap-fixes/OTP-8332:
Fix assymetric (Un)UseTmpHeap in erl_process.c
Conflicts:
erts/emulator/beam/beam_emu.c
|
|
* rickard/temp_alloc_check/OTP-9028:
Verify that temp allocated memory is released
|
|
The halfword emulator used to require special handling,
but no longer does.
|
|
It is not necessary to decrement I, because an exception is
about to be generated. Furthermore, I pointing *before* the
instruction that caused the exception may cause problems in
the future.
|
|
|
|
This commit fixes four related bugs:
- calling hibernate/3 using a dynamic call would fail with badarg
as hibernate/3 as a BIF was not implemented. hibernate/3 is generally
provided as a Beam instruction, and code is translated to use this
instruction when loaded.
- calling hibernate/3 from HiPE would fail with badarg because this
would call the aforementioned BIF which was not implemented.
- calling hibernate/3 with some HiPE-native garbage in the process heap
would randomly crash at the next garbage collect. This bug only
happened in a complex, yet reproduceable scenarios, where native code
calls beam code that calls hibernate/3, and the process has some
garbage when being hibernated and the process generates garbage when
awaken.
- when entering HiPE, the process current_function can be set and be
inaccurate.
The fix is three folded:
- hibernate_3 BIF now actually works instead of throwing a badarg. While
hibernate_3 BIF was (usually) not called from BEAM, it is called from
HiPE. hibernate behaviour is very close to the scheduler and this is why
it is implemented as an instruction in BEAM. The fix consists in doing
the actual hibernation (through the now exported erts_hibernate
function) and setting the process flag to TRAP as well as the process
status to P_WAITING. On BIF epilogue in both BEAM and HiPE, this status
is tested on TRAP and if set, the scheduler is invoked. The i_hibernate
instruction and translation code is now redundant and could be deleted.
- hibernation now also empties the HiPE native stack, with a new
function hipe_empty_nstack provided by Mikael Pettersson.
- when entering HiPE through hipe_mode_switch, p->current is cleared,
as suggested by Mikael Pettersson. p->current normally hold a pointer to
the {M,F,A} of the current function if it exists. When hibernating, it
is set to {erlang,hibernate,3}, and all stdlib hibernate tests
(gen_server_SUITE:hibernate/1, proc_lib_suite:hibernate/1, etc.)
actually rely on this information. Clearing p->current fixes the tests
and avoids the surprise one might have when querying the process info
of a process that hibernated and woke up in a native function.
Non-regression tests are provided, a test for the dynamic call as well
as a Makefile-handled duplication of the hibernate_SUITE into
hibernate_native_SUITE for the HiPE case.
|
|
Frequency counts show that
move Const x(1)
move Const x(2)
are very common.
|
|
That will save one word and small amount of time for
each occurrence.
|
|
The is_eq_exact/3 and is_ne_exact/3 instructions are commonly used
with one immediate or literal operand.
Introduce three new specialized instructions:
i_is_eq_exact_literal/3
i_is_ne_exact_immed/3
i_is_ne_exact_literal/3
The i_is_ne_exact_literal/3 instruction is not very frequently
used, but its existence is justified because we removed in a
a previous commit the special instruction for matching bignums
and we now use i_is_ne_exact_literal/3 instead.
For consistency, rename the existing is_eq_immed/3 instruction to
is_eq_exact_immed/3.
While at it, remove the optimization of an is_eq/3 instruction
with an immediate operand because that optimization is already
done by the compiler.
|
|
Introduce a new i_increment/4 to optimize the addition of
a register and a small integer. This instruction saves two
instruction words compared to the standard instructions
(an i_fetch/2 instruction followed by a i_plus/3 instruction)
and will also be slightly faster.
|
|
The new instruction will save one word (because no size operand
is needed), and is slightly faster.
Handle select_tuple_arity in the same way.
|
|
Create separate instructions for each register type. The "badmatch x(0)"
and "case_end x(0)" (which are very common) will only require a single
word each, compared to two words when GetArg1() is used.
|
|
Use separate instructions for each register type.
|
|
Use separate instructions for each register type.
|
|
|
|
Instead of having one i_select_val_sfI instruction that uses
the GetArg1() macro to fetch the controlling expression, use
three separate instructions for each of the register types.
That will save one word when selecting on the {x,0} register.
It should also be slightly faster since a conditional branch
is eliminated.
Although it seems that the BEAM compiler will never generate
a constant controlling expression (even with optimizations
turned off), we still make sure that they will work by
evaluating the select_val instruction at load time.
Handle the select_tuple_arity instruction in the same way.
|
|
The tmp_arg1 and tmp_arg2 variables are intended for transferring
values from the fetch/2 instructions to instructions such as
i_plus/3. In many places, however, tmp_arg1 and tmp_arg2 are used
as general temporary variables within a single instruction.
Improve the code generation by replacing sloppy use of tmp_arg1
and tmp_arg2 with block-local variables. In most cases, that will
allow the temporary values to be kept in registers.
|
|
By default, GCC will inline calls to helper functions. Since
process_main() is already huge, there is no reason to inline
the helper functions (and some of them are used very seldom).
|
|
There were two separate functions (call_error_handler() and
call_breakpoint_handler()) that were identical except for
the name of the function in the error_handler module being
called. Generalize call_error_handler() by adding a function
name argument so that it can be used for both purposes.
Also let the call_error_handler() return the new program
counter instead of passing it in c_p->i. That slightly decrease
the code size at the call site.
There is also no need to use the Dispatch() macro to yet again
decrease the reduction counter, because that has just been done by
the call instruction that caused the execution of the
call_error_handler or i_debug_breakpoint instruction.
|
|
Combine the put_tuple/2 and all following put/1 instructions
to one i_put_tuple/2 instruction. In general, that will reduce
the number of instruction words by 50 percent.
Measurements seem to indicate that the speed is about the same.
|
|
|
|
In many (not all) cases, the value for the 'I' type will
fit into 32 bits.
|
|
|
|
Introduce a new 'Q' type, similar to 'P' except that it
can be packed.
|
