| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These have never worked in binary matching (including sub-binaries
extracted from them) so it's hard to justify their existence. They
also make a future migration of binary sizes from bytes to bits
problematic, so we may as well change it ahead of time.
This is potentially incompatible on 32-bit platforms where a NIF
or driver could allocate 512MB+ binaries, but allocations that
large should be expected to fail anyway.
|
|
into sverker/master/enif_whereis_pid-dirty-dtor
|
|
to run user NIF code in a more known execution context.
Fixes problems like user calling enif_whereis_pid() in destructor
which may need to release process main lock in order to lock reg_tab.
|
|
Summary: This commit simplifies the implementation of the "GC BIFs" so
that they no longer need to do a garbage collection, removing duplicate
code for all GC BIFs in the runtime system, as well as potentially
reducing the size of the loaded BEAM code by using shorter
instructions calling those BIFs.
A GC BIF is a guard BIF that will do a garbage
collection if it needs to build anything on the heap.
For example, `abs/1` is a GC BIF because it might need to
allocate space on the heap (if the result is a floating point
number or the resulting integer is a bignum).
Before R12, a guard BIF (such as `abs/1`) that need to allocate
heap space would allocate outside of process's main heap, in
a heap fragment.
GC BIFs were introduced in R12B to support literals. During garbage
collection it become necessary to quickly test whether a term was
a literal. To make the check simple, guards BIFs were no longer
allowed to create heap fragments. Instead GC BIFs were introduced.
In OTP 19, the implementation of literals was changed to support
storing messages in heap fragments outside of the main heap for a
process. That change again made it allowed for guard BIFs to create
heap fragments when they need to build terms on the heap.
It would even be possible for the guard BIFs to build directly
on the main heap if there is room there, because the compiler
assumes that a new `test_heap/2` instruction must be emitted
when building anything after calling a GC BIF. (We don't do that
in this commit; see below.)
This commit simplifies the implementation of the GC BIFs in
the runtime system.
Each GC BIF had a dual implementation: one that was used when the GC
BIF was called directly and one used when it was called via
`apply/3`. For example, `abs/1` was implemented in `abs_1()` and
`erts_gc_abs_1()`. This commit removes the GC version of each BIF. The
other version that allocates heap space using `HAlloc()` is updated to
use the new `HeapFragOnlyAlloc()` macro that will allocate heap
space in a heap fragment outside of the main heap.
Because the BIFs will allocate outside of the main heap, the same
`bif` instructions used by nonbuilding BIFs can be used for the
(former) GC BIFs. Those instructions don't use the macros that save
and restore the heap and stack pointers (SWAPOUT/SWAPIN). If the
former GC BIFs would build on the main heap, either new instructions
would be needed, or SWAPOUT/SWAPIN instructions would need to be added
to the `bif` instructions.
Instructions that call the former GC BIFs don't need the operand
that specifies the number of live X registers. Therefore, the
instructions that call the BIFs are usually one word shorter.
|
|
|
|
|
|
|
|
|
|
|
|
to replace macro ERTS_INTERNAL_BINARY_FIELDS
as header in Binary and friends.
|
|
|
|
|
|
Only term_to_binary needed some extra attention
as it used to initialize refc as 0 instead of 1.
|
|
In many cases sub-binaries costs more memory than converting them to heap-binaries.
Sub-binaries also has a hidden cost of pinning larger binaries in memory.
By converting binaries this cost is reduced.
Byte aligned sub-binaries upto 24 bytes (64-bit) or 12 bytes (32-bit) are converted.
|
|
|
|
A magic destructor can return 0 and thereby take control
and prolong the lifetime of a magic binary.
|
|
|
|
Magic references are *intentionally* indistinguishable from ordinary
references for the Erlang software. Magic references do not change
the language, and are intended as a pure runtime internal optimization.
An ordinary reference is typically used as a key in some table. A
magic reference has a direct pointer to a reference counted magic
binary. This makes it possible to implement various things without
having to do lookups in a table, but instead access the data directly.
Besides very fast lookups this can also improve scalability by
removing a potentially contended table. A couple of examples of
planned future usage of magic references are ETS table identifiers,
and BIF timer identifiers.
Besides future optimizations using magic references it should also
be possible to replace the exposed magic binary cludge with magic
references. That is, magic binaries that are exposed as empty
binaries to the Erlang software.
|
|
|
|
* ERTS_GET_BINARY_BYTES_REL
* ERTS_GET_REAL_BIN_REL
|
|
|
|
|
|
Caused bus error on 32-bit sparc from unaligned 64-bit word in
binary_to_term trap context.
Also add _UNALIGNED_ magic macros to avoid double alignment padding
in NIF resources.
|
|
except the reference counter 'refc', as different callers
have different strategies regarding the lifetime of the binary.
|
|
|
|
- erlang:list_to_binary/1
- erlang:iolist_to_binary/1
- erlang:list_to_bitstring/1
- binary:list_to_bin/1
|
|
* sverk/bin2term-bitstr-bugs/OTP-11479:
erts: Fix bug in binary_to_term for binaries larger than 2^31
erts: Fix bugs in binary_to_term for invalid bitstrings
|
|
<<131, 77, Len:32, Bits:8, Data/binary>>
badarg if Bits > 8
Used to return internally inconsistent bitstring
badarg if Len==0 and Bits > 0
Used to return invalid *huge* binary (size = (Uint)-1)
badarg if Bits==0 and Len > 0
Used to return valid binary as if Bits was 8
|
|
|
|
Introduce unconditional ERTS_ASSERT
and use that for both ASSERT and ASSERT_EXPR.
|
|
|
|
In halfword emulator, make ETS use a variant of the internal term
format that uses relative offsets instead of absolute pointers. This
will allow storage in high memory (>4G). Preprocessor macros (like
list_val_rel(TERM,BASE)) are used to make normal (fullword) emulator
almost completely unchanged while still reusing most of the code.
|
|
|
|
Add the gc_bif's to the VM.
Add infrastructure for gc_bif's (guard bifs that can gc) with two and.
three arguments in VM (loader and VM).
Add compiler support for gc_bif with three arguments.
Add compiler (and interpreter) support for new guard BIFs.
Add testcases for new guard BIFs in compiler and emulator.
|
|
Add testcases for binary:list_to_bin/1 and binary:copy/1,2.
Add reference implementation of list_to_bin/1.
|
|
Add allcoator parameter to erts_get_aligned_binary_bytes_extra.
Add testcases for the functions above.
Add reference implementation for the functions above.
|
|
Store Erlang terms in 32-bit entities on the heap, expanding the
pointers to 64-bit when needed. This works because all terms are stored
on addresses in the 32-bit address range (the 32 most significant bits
of pointers to term data are always 0).
Introduce a new datatype called UWord (along with its companion SWord),
which is an integer having the exact same size as the machine word
(a void *), but might be larger than Eterm/Uint.
Store code as machine words, as the instructions are pointers to
executable code which might reside outside the 32-bit address range.
Continuation pointers are stored on the 32-bit stack and hence must
point to addresses in the low range, which means that loaded beam code
much be placed in the low 32-bit address range (but, as said earlier,
the instructions themselves are full words).
No Erlang term data can be stored on C stacks (enforced by an
earlier commit).
This version gives a prompt, but test cases still fail (and dump core).
The loader (and emulator loop) has instruction packing disabled.
The main issues has been in rewriting loader and actual virtual
machine. Subsystems (like distribution) does not work yet.
|
|
|
|
|
|
tile-cc 2.0.1.78377 when compiling the runtime system.
|
|
|
