- Don't coalesce IFS nor interpret backslash at the output of `find'.
- The argument of -m and -l can now be arbitrary.
- The TC39 test262 path and/or files can now be arbitrary.
Previously any of those broke on IFS chars at the value.
Now the only issue is (unlikely) newline at filenames - from `find'.
tools: add test262-harness.js to run a single test
Usage: mujs <this-file> -- [-f] [-l file1.js -l ...] suit-root test-file
-f: print full paths/stacktraces if possible
-l: load a js file after the harness and before the test (to override things)
tools: add test-262 launcher
It can run the entire suite or just a sub-folder or one file, and by
default it skips tests which are known to crash/hang.
test262-harness: @negative: match regex if exists
Some @negative tests add a regex which needs to match the error.
This wasn't tested, and now it is. This results in few more failures.
The actual string to compare is not documented, but it appears to be
err.message for plain Error(..) where the message is always compared
to "NotEarlyError" (equals/different), and err.name for anything else.
test262 launcher: minor improvements and custom mujs path
- Use getopts instead of custom arguments parsing
- Support -m path/to/mujs
- Change -s (skip bad tests) to -b, and add -B to run only bad tests
(useful when trying to update the known bad tests list).
- Combine stderr to stdout on a per-test basis (mujs function warnings)
- Exit with error if failures > 0
test262: remove 5 tests which no longer crash/hang
test262 and harness: support -s to print failed source
test262 and harness: convert spaces to tabs
Use a specialized array initializer that pushes values to the end
of the array instead of using a lot of setprop. This avoids the need
to create a lot of number constants for the array indices.
Change default optimization flag to -O2.
Use XCFLAGS and XCPPFLAGS to add to the definitions:
make XCPPFLAGS=-I/foo/bar XCFLAGS=-mfoo-bar
Set CFLAGS on the make command line if you want to override completely:
make CFLAGS="-O3 -m32"
If you want to override them with the system environment variables:
make CFLAGS="$CFLAGS"
The problem with a fixed count value is that it result in varying
degrees of performance and memory impact proportions depending on
the usage pattern of each script.
E.g. if a script keeps using the same 1M objects, then a threshold of
10K objects will result in GC cycles which free only 1% of objects,
which is hugely wasteful in terms of performance. On the other hand,
if a script only uses 100 objects then a threshold of 10K means it
uses 100 times more memory than it actually needs before GC triggers.
Now the threshold is a target memory usage factor (of the minimum
needed memory) which GC tries to aim at. This makes the GC impact
have constant proportions.
The default aims at a memory usage factor of 5, i.e. 80% garbage
and 20% remaining on each GC cycle.
The factor is only a target/goal because the actual overhead is not
known until GC completes. However, most scripts exhibit consistent
enough behavior such that the real overhead is within 10% or less of
the goal even when the usage pattern changes over time.
Within the v8 bench test suite, the actual GC threshold count varies
between ~50K to ~500K, where only one test (raytrace.js) stabilizes on
less than 10K (the previous fixed default) - at about 9K and its score
decreases by ~5%.
The splay.js score increases about x12 fold (or x50 fold from the
previous commit which counts properties), other tests quite a bit
less or none at all, and the overall score increases by nearly 40%.
Also, change the count type from int to unsigned int to get twice the
range. Preferably we should make it even bigger, maybe uint64_t.
For instance the splay.js v8 bench test surpasses million non-garbage
allocations within few seconds (that's why its score increased so much
with a proportional overhead), and the default GC threshold is 5 times
that number.
They're not negligible in the overall count.
This decreases the performance of scripts which use objects with many
properties because the GC threshold remains the same (10K) but it's
reached quicker due to counting more allocations, so GC is more
frequent and wastes more overall time.
Good example of the performance impact is the splay.js v8 bench test,
where this commit reduces its score by a factor of 5.
We're not changing the threshold because it's arbitrary anyway, but the
next commit will change it in a way which allows more proportional
control of the GC overhead.
When scanning an iterator object, the iterated object was marked
unconditionally. Now it's marked only if it's not already marked - like
all other object markings.
This code was incorrect for some years, but wasn't really an issue
before commit 331c5ec because marking an object twice simply used some
more CPU cycles but otherwise without issues - unless there were cycles,
and apparently typically/always there never were cycles with iterators,
so it was hard/impossible to behave badly.
However, since 331c5ec, marking an object means inserting it into a
linked list where the list nodes are part of the object, therefore
marking the same object twice now creates a broken linked list.
A broken list means that some objects are skipped while scanned, which
means they don't get marked even when they should, and as a result
freed incorrectly while still referenced by other objects, resulting in
random errors related to use-after-free.
The following functions are no longer restricted to 16-bit integer values:
String.fromCharCode()
String.prototype.charCodeAt()
repr() will not escape SMP characters, as doing so would require conversion to
surrogate pairs, but will encode these characters as UTF-8. Unicode characters
in the BMP will still be escaped with \uXXXX as before.
JSON.stringify() only escapes control characters, so will represent all non-ASCII
characters as UTF-8.
We do no automatic conversions to/from surrogate pairs. Code that worked with
surrogate pairs should not be affected by these changes.
We're supposed to check whether a string turned into an integer and back
is itself, while also returning the value of the integer. We were
unintentionally allowing integers with leading zero through.
