* Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may
cause some sign warnings in calling code.
* Reject attempt to unpack an array-like value whose length is 2G or over;
previously was not checked explicitly, and the length was cast to duk_idx_t
with a sign change and the unpack would then later fail. Now it fails with
a clean RangeError.
* Add wrap check for Node.js Buffer.concat().
* API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
* Replace the two alternative algorithms with a single one which works for
both desktop and low memory cases.
* Basic algorithm is a hash table with size 2^N, hash mask is simply
(size - 1), e.g. if size is 0x100, mask is 0xFF. duk_hstring has a 'next'
pointer (single linked list) for chaining strings mapping to the same
slot.
* Strings with 0xFF byte prefix are considered special symbols: they have
typeof "symbol" but still mostly behave as strings (e.g. allow ToString)
so that existing code dealing with internal keys, especially inside
Duktape, can work with fewer changes.
* Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo')
creates the byte representatio: 0x80 "foo"
* Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed
by the Symbol description, and an internal string component ensuring
uniqueness is separated by a 0xFF byte (which can never appear anywhere in
an extended UTF-8 string). The unique suffix is up to Duktape internals,
currently two 32-bit counters are used. For example:
0x81 "mySymbol" 0xFF "0-17".
* Well-known symbols use the 0x81 prefix but lack a unique suffix, so their
format is 0x81 <description> 0xFF.
* ES6 distinguishes between an undefined symbol description and an empty
string symbol description. This distinction is not currently visible via
Ecmascript bindings but may be visible in the future. Append an extra
0xFF to the unique suffix when the description is undefined, i.e.
0x81 0xFF <unique suffix> 0xFF.
Previous implementation avoided side effects during string table resize.
This is sufficient in most cases but not in the following:
- Caller pushes a string using duk_push_lstring(), with the data and
length referencing the data area of a dynamic or external buffer.
- When allocating a new duk_hstring a side effect triggers a finalizer.
- The finalizer resizes or reconfigures the dynamic/external buffer so
that the original duk_push_lstring() arguments are invalidated.
- When it's time to copy the data over into the duk_hstring, the pointer
and/or length are invalid and memory unsafe behavior follows.
Avoid this problem by preventing mark-and-sweep side effects for the duration
of the entire string intern processing.
These don't play well with the API currently: the Duktape specific error
codes don't have Ecmascript Error class counterparts so they don't get
represented usefully as Ecmascript objects (e.g. AllocError is a plain
Error from Ecmascript point of view).
There's no real need for Duktape specific error code. Some of the codes
had become unused; a couple were used but Ecmascript standard types can
be used instead.
Also minor error message tweaking.
* Use shared error macros and shared error handler to reduce the size of call
sites of common errors.
* Make zero argument DUK_ERROR() calls non-vararg calls to reduce call site
footprint. Non-vararg calls have smaller call sites and because there are
a lot of call sites, this turns out to be significant.
* Remove variadic macros from internal DUK_ERROR() macro set and add separate
macros for argument counts 0 to 4; this is more portable and requires less
conditional code, and works well when a non-vararg call is used for most
error call sites.
* Rework macro / function argument order for the error path, try to keep 'thr'
in the same argument slot to avoid unnecessary register moves.
* Pack linenumber and error code into a single 32-bit argument when possible,
removes one more constant load from the call site.
* Convert some internal errors to RangeErrors when the underlying cause is an
implementation limit (such as a compiler temp limit) rather than an actual
unexpected internal situation.
* Simplify and share a few error messages to reduce string count.
- Endianness for pointers and IEEE doubles
- Add DUK_OPT_DEBUGGER_DUMPHEAP feature option
- Add DUK_OPT_DEBUGGER_DUMPHEAP to Makefile
- Refactor executor and executor interrupt debugger handling to separate
functions to make them easier to read
- Explicit peek, read flush, and write flush callbacks
- Remove brkpt_dirty, easier and perhaps more robust to recheck breakpoints
whenever any debug commands have been executed
- Bug fixes, FIXME resolutions, trivia
Also remove mostly unused old debug code.
Debug code doesn't have access to 'heap' so it cannot decode pointers.
Cause an #error for now if both debug prints and pointer compression
are enabled at the same time.
Remove duk_debug_hobject.c from make and dist. It was out of date and
not used in practice anymore.
Use DUK_DPRINT instead of DUK_DPRINTF for heap stringtable dumps. This makes
the dump output go to stderr instead of stdout which is useful because it
allows e.g. testcase runs with debugs enabled.
Also fix typo which breaks compilation when using "chain" stringtable and no
pointer compression.
Memory optimization work for very low memory devices (96 to 256kB system RAM).
Overall changes are:
- 16-bit fields for various internal structures to reduce their size
- Heap pointer compression to reduce pointer size to 16 bits
When DUK_OPT_LIGHTFUNC_BUILTINS and the new low memory options are enabled,
Duktape initial heap memory usage is about 23kB (compared to baseline of
about 45kB) on x86.
Unless low memory feature options are enabled, there should be no visible
changes to Duktape behavior.
More detailed changes:
- 16-bit changes for duk_heaphdr: pointer compression, refcount
- 16-bit changes for duk_hstring: hash, blen, and clen can all be 16 bits,
use 0xFFFF as string byte length limit (call sites ensure this limit is
never exceeded)
- 16-bit changes for duk_hbuffer, use 0xFFFF as buffer length limit
- 16-bit fields for hobject size (entry part, array part), drop hash part
since it's not usually needed for extremely low memory environments
- 16-bit changes for duk_hcompiledfunction
- Heap pointer packing for stringtable
- Heap pointer packing for 'strs' built-in strings list (saves around 600
to 700 bytes but may not be a good tradeoff because call site size will
increase)
Other changes:
- Heaphdr NULL init fix. The original macros were broken: the double/single
linked macro variants were the wrong way around. Now sets through macro
to work properly with compressed pointers.
- Rename duk_hbuffer CURR_DATA_PTR -> DATA_PTR to reduce macro length
(previous name was tediously long)
- Rename buffer "usable_size" to "alloc_size" throughout as they have been
the same for a while now (they used to differ when buffer had an extra NUL).
- Add memory optimization markers to Duktape.env (pointer compression and
individual 16-bit field options)
- Rename a few internal fields for clarity: duk_hobject 'p' to 'props',
heap->st to heap->strtable
- Add a safety check for buffer alloc size (should not be triggered but
prevents wrapping if call sites don't properly check for sizes)
- Other minor cleanups
These were revealed after fixing DUK_SINGLE_FILE, gcc will complain about
these internal functions being declared, defined, but not used. There were
also a few declared functions that did not exist. Compiled binary size was
reduced by a few kilobytes!
Unused functions must be commented out carefully: some functions might be
used with certain feature options but not by the defaults. These removals
were verified with grep.
There are no call sites for DUK_DEBUG_DUMP_HEAP() so all the functions
in duk_debug_heap.c are unused, even with a debug build.
Out of the checked allocation macros, only DUK_REALLOC_INDIRECT_CHECKED() is
actually in use at the moment. This commit just comments the unused stuff
out, but it might be better to just remove the unused stuff entirely.
This allows user code to create internal properties too, so that the
internal properties are not returned by e.g. getOwnPropertyNames().
Prior to this change, a user string beginning with \xFF would not be
treated as internal - unless it happened to be a string already used
by Duktape for its own purposes. This is quite confusing.
Sami Vaarala