Age | Commit message (Collapse) | Author |
|
* egil/core-on-heart-tmo/OTP-12613:
kernel: Document heart environment HEART_KILL_SIGNAL
erts: Enable different abort signal from heart
|
|
* egil/opt-float-cmp:
erts: Brute force float comparisons as well
|
|
* i_rem specialization on x registers
|
|
* i_band specialization on x registers and constants
|
|
check (nbytes == 0 && d->c.sendfile.nbytes == 0) when efile_sendfile returns 0 and
has EAGAIN set.
FreeBSD sendfile(2) man page:
When using a socket marked for non-blocking I/O, sendfile() may send
fewer bytes than requested. In this case, the number of bytes
successfully written is returned in *sbytes (if specified), and the error
EAGAIN is returned.
The number of bytes successfully written can be 0. If this happens and
in a request handling either file:sendfile/2 or file:sendfile/5 with Bytes=0,
the sendfile loop will stop prematurely and file:sendfile will return
{ok, BytesSent} where BytesSent < DataAfterOffset, effectively breaking sendfile
support on FreeBSD.
|
|
May lessen load/store latency.
|
|
A type error caused the optimization to never kick in.
|
|
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
|
|
|
|
* 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
|
|
This fixes arity 4 BIF support in HiPE, following its introduction
on master (OTP 18) via the nox/ets-update_counter-4 merge.
- define standard_bif_interface_4, nbif_4_gc_after_bif, and
nbif_4_simple_exception on ARM: unbreaks the build on ARM
- remove bogus stack re-alignment from standard_bif_interface_4
on AMD64: for 4-arg BIFs the stack is already aligned, and the
code would misalign the C stack which violates the ABI and may
cause alignment faults in vectorized code
- the nbif_4_simple_exception OPD name on PPC64 was incorrectly
using the nbif_3_simple_exception OPD name: this would have
caused a multiple definition error in the assembler or linker
In addition there are a few cleanups:
- fix standard_bif_interface_N comment on x86
- fix standard_bif_interface_4 comment on SPARC
- separate nbif_N_simple_exception blocks by empty lines on PPC,
like on ARM, to clearly show which things belong together
- fix standard_bif_interface_N comment on ARM
- fix standard_bif_interface_4 on AMD64 to match the indentation
and spacing conventions of the rest of that file
|
|
* sverk/pr632/prevent-illegal-nif-terms/OTP-12655:
erts: Reject non-finite float terms in erl_drv_output_term
erts: Remove old docs about experimental NIF versions.
erts: Add enif_has_pending_exception
erts: Clearify erl_nif documentation about badarg exception
erts: Fix compile warning in enif_make_double
erts: Fix divide by zero compile error in nif_SUITE.c
erts: Fix isfinite for windows
Ensure NIF term creation disallows illegal values
|
|
Increases float comparison speed by ~120%
|
|
* sverk/etp-map:
erts: Add map support to gdb etp command
erts: Add etp_the_non_value
|
|
Only call emasculate_binary if ProcBin.flags is set,
which means it's a writable binary.
|
|
* mikpe/configure-linux-spelling:
erts/configure.in: handle more 'linux' spellings
|
|
|
|
Seen symptom: Hipe compiled code with <<C/utf8, ...>> = Bin does sometimes
not match even though Bin contains a valid utf8 character. There might be
other possible binary matching symptoms, as the problem is not utf8
specific.
Problem: A writable binary was not "emasculated" when the matching started
(as it should) by the hipe compiled code.
Fix: Add a new primop emasculate_binary(Bin) that is called when
a matchstate is created.
ToDo: There are probably room for optimization. For example only call
emasculate_binary if ProcBin.flags is set.
|
|
By using environment variable HEART_KILL_SIGNAL, heart can now use
a different signal to kill the old running Erlang.
By default the signal is SIGKILL but SIGABRT may also be used by
setting environment variable: HEART_KILL_SIGNAL=SIGABRT
|
|
The configuration code which canonicalizes the operating system
name into OPSYS requires Linux to be spelled 'linux' or 'Linux'.
This is a problem in some build environments, e.g. RPM, which
supply --build and --host using the longer 'linux-gnu' spelling.
The effect is that OPSYS becomes 'noopsys' and some checks in
erts/configure.in do not work as expected, e.g. the auto-enabling
of HiPE may not happen.
Fixed by matching on 'linux*' not just 'linux'.
On ARM there are even longer variants such as 'linux-gnueabi' and
'linux-gnueabihf': these are also correctly mapped to 'linux' now.
|
|
|
|
* egil/cmp-immediate-optimization/OTP-12663:
erts: Optimize comparison operator for frequent immediates
|
|
* Assertion is only removed because we are in icount mode.
|
|
* We use compile directive icount instead
|
|
* egil/maps-refactor:
erts: Use make_small for size terms on flat maps
Conflicts:
erts/emulator/beam/erl_bif_guard.c
|
|
* bjorn/maps:
Document the new {badmap,Term} and {badkey,Key} exceptions
Raise more descriptive error messages for failed map operations
erl_term.h: Add is_not_map() macro
Tigthen code for the i_get_map_elements/3 instruction
Pre-compute hash values for the general get_map_elements instruction
Teach the loader to pre-compute the hash value for single-key lookups
Optimize use of i_get_map_element/4
beam_emu: Slightly optimize update_map_{assoc,exact}
v3_codegen: Don't sort map keys in map creation/update
beam_validator: No longer require strict literal term order
Sort maps keys in the loader
De-optimize the has_map_fields instructions
erts/map_SUITE.erl: Add a test case that tests has_map_fields
Fully evaluate is_map/1 for literals at load-time
map_SUITE: Add tests of is_map/1 with literal maps
Run a clone of map_SUITE without optimizations
Remove the fail label operand of the new_map instruction
Correct transformation of put_map_assoc to new_map
Remove support for put_map_exact without a source map
|
|
* egil/refactor-message-queue-probes:
erts: Refactor dtrace call probes
erts: Refactor erts_queue_message
|
|
* sverk/nlmills-pr653/efile-union-pwritev/OTP-12653:
erts: Cleanup code in invoke_pwritev
Use the correct union member inside efile_drv
|
|
|
|
|
|
|
|
Also state that maximum atom length is 255 characters.
|
|
|
|
|
|
Add macro erts_isfinite as an OS independent way to check
if a float is finite.
|
|
* small integers
* atoms
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
|
|
|
|
* egil/fix-maps-match_spec-return/OTP-12656:
erts: Fix building of Map result from match_specs
|
|
|
|
|
|
Different poll/select implementations have different ways
to handle timeouts of < ms accuracy. Most have extended
API like pselect or such, while others rely on using
timerfds (epoll_wait). If no high accuracy timeout is
available, we simply round up to nearest ms. If we do not
roundup we will spin the last ms when waiting for a timeout
which is not desirable.
|
|
For consistency with other data types, add the is_not_map() macro.
|
|
|
|
See the previous commit for justification and use cases.
|
|
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).
|
|
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.
|
|
In the update loop for big maps, the E variable is restored for
each turn of the loop. It only needs to be restored if a garbage
collection has been performed.
Also add a new test case that attempts to force several garbage
collections while updating a map, to help us find bugs with
incorrect restoration of the E variable after a garbage collection.
|
|
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).
|