aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/external.h
AgeCommit message (Collapse)Author
2011-11-17external.c: Remove the option to create over-sized heap binariesBjörn Gustavsson
Since refc binaries are now supported in literal pools, there is no longer any need to allow the creation of over-sized heap binaries.
2011-09-29Update copyright yearsBjörn-Egil Dahlberg
2011-08-27Add erlang:external_size/2 BIFFilipe David Manana
This BIF's second parameter is a list of options. Currently the only allowed option is {minor_version, Version} where version is either 0 (default) or 1.
2010-11-22ETS 'compressed' option.Sverker Eriksson
The compressed format is using a slighty modified variant of the extern format (term_to_binary). To not worsen key lookup's too much, the top tuple itself and the key element are not compressed. Table objects with only immediate non-key elements will therefor not gain anything (but actually consume one extra word for "alloc_size").
2010-08-07Align trailing message data for all types of structuresRickard Green
Alignment of trailing data in messages has been adjusted. This in order to be able to pass data of any type as trailing data in the future.
2010-03-10Store pointers to heap data in 32-bit wordsPatrik Nyblom
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.
2010-01-12Merge branch 'jv/binary_to_term-opts' into ccase/r13b04_devErlang/OTP
* jv/binary_to_term-opts: document ErtsExternalDist flags and CON_ID mask add options to binary_to_term OTP-8367 There is new erlang:binary_to_binary/2 BIF that takes an option list. The option safe can be used to prevent creation of resources that are not garbage collected (such as atoms). (Thanks to Jayson Vantuyl.)
2010-01-08document ErtsExternalDist flags and CON_ID maskJayson Vantuyl
In the ErtsExternalDist structure, the flags field holds a combination of flags (tagged into the high bits) and the connection ID (in the low bits). This wasn't clearing indicated anywhere. This patch adds a comment before the flags and mask that indicates their use and relation to each other. This will help guide people through the code and reduce the likelihood that someone will add a flag without adjusting the mask.
2010-01-08add options to binary_to_termJayson Vantuyl
term_to_binary and binary_to_term are powerful tools that can be used easily in lieu of a custom binary network protocol. Unfortunately, carefully crafted data can be used to exhaust the memory in an Erlang node by merely attempting to decode binaries. This makes it unsafe to receive data from untrusted sources. This is possible because binary_to_term/1 will allocate new atoms and new external function references. These data structures are not garbage collected. This patch implements the new form of binary_to_term that takes a list of options, and a simple option called 'safe'. If specified, this option will cause decoding to fail with a badarg error if an atom or external function reference would be allocated. In the general case, it will happily decode any Erlang term other than those containing new atoms or new external function references. However, fun, pid, and ref data types can embed atoms. They might fail to decode if one of these embedded atoms is new to the node. This may be an issue if encoded binaries are transferred between nodes or persisted between invocations of Erlang.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP