How does JavaScript decide how much memory to allocate for a numeric value?
Programming languages like Java / C have int, long, byte, etc. that tell the interpreter exactly how much memory it should allocate for a number at runtime. This saves a lot of memory if you are dealing with a lot of variables.
I'm wondering how programming languages that don't have this primitive variable type declaration (JavaScript, Ruby) decide how much memory is allocated for let say var a = 1
. If it allocates, say 1 byte, then on the next line, if I do a = 99999999999
, it will have to pull that variable and reallocate it. Wouldn't it be an expensive operation?
Or they allocate a very large memory space for all variables, so one size fit all
source to share
JavaScript values
The JS :: Value type represents a JavaScript value.
The representation is 64 bits and uses a NaN box on all platforms, although the exact format of the NaN box is platform dependent. NaN boxing is a technique based on the fact that there are 2 ** 53-2 different bit patterns in IEEE-754, which all represent NaN. Hence, we can encode any floating point value as a C ++ double (noting that JavaScript NaN must be represented as one canonical NaN format). Other values are encoded as value and tag like:
On x86, ARM and similar 32-bit platforms, we use what we call "nunboxing", in which the non-double values represent a 32-bit type tag and a 32-bit payload, which is usually either a pointer or a signed 32-bit a bit integer. There are several special values: NullValue (), UndefinedValue (), TrueValue (), and FalseValue (). On x64 and similar 64-bit platforms, pointers are longer than 32 bits, so we cannot use the nunboxing format. Instead, we use "punboxing" which has 17 tag bits and 47 payload bits. Only the JIT code really depends on the layout - everything else in the engine interacts with values via the val.isDouble () functions. Most of the JIT parts are also avoided depending on the layout: the PunboxAssembler.h and NunboxAssembler files.h are used to generate native code that depends on the value.
Objects consist of a possibly general structural description called a map or scope; and unshared property values in a vector called slots. Each property has an id, either a non-negative integer or atom (a unique string) with the same pointer-pointer encoding as jsval.
The atomic manager consists of a hash table linking strings unambiguously to the scanner / parser information such as keyword type, index in script, or functional literal pool, etc. Atoms play three roles: as literals that are referenced by unaligned 16-bit immediate bytecode operands, as unique string descriptors to efficiently hash a property name, and as root GC members for exact GC.
According to W3Schools:
This format stores numbers in 64 bits, where the number (fraction) is stored in bits from 0 to 51, the exponent is in bits 52-62, and the sign is in bit 63:
Value (aka Fraction / Mantissa): 52 bits (0 - 51)
Index: 11 bits (52 - 62)
Sign: 1 bit (63)
Also read this article here .
source to share