aboutsummaryrefslogtreecommitdiffstats
path: root/erts/lib
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2018-12-03 10:23:15 +0100
committerBjörn Gustavsson <[email protected]>2018-12-13 10:31:22 +0100
commit3691c6ab52ace5a3f0c1ddf51b7ab6e0b9abb385 (patch)
tree52a10fc4ec361d4dca69186d9bfc1d30d5d52b47 /erts/lib
parentf19a52e92ae56b8e5248064db56dc38c0d7dff69 (diff)
downloadotp-3691c6ab52ace5a3f0c1ddf51b7ab6e0b9abb385.tar.gz
otp-3691c6ab52ace5a3f0c1ddf51b7ab6e0b9abb385.tar.bz2
otp-3691c6ab52ace5a3f0c1ddf51b7ab6e0b9abb385.zip
Simplify GC BIFs
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.
Diffstat (limited to 'erts/lib')
0 files changed, 0 insertions, 0 deletions