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.
We normally build as one compilation unit with "one.c" but we should
still be able to build each source file as a separate compilation unit
if desired.
Since js_tostring can invoke a toString method, we should guard against
uncaught exceptions when trying to convert the error object to a string.
Add a public function, js_trystring that does a "safe" conversion
to a string.
Revert 'add context and flag argument to js_newstate' commit.
The context argument just adds clutter. The flag which was intended
for JS_DEBUG and/or JS_STRICT shouldn't be necessary.
js_newcfunction and js_newcconstructor need an extra argument, the
name of the function to use in stack traces.
Add a separate js_loadeval for "eval code" scripts, and let
js_do/loadstring create "global code" scripts.
js_newscript called with the NULL scope is equivalent to 'eval code'.
js_newscript called with the J->GE scape is equivalent to 'global code'.
js_newfunction is created with the lexical scope, i.e. 'function code'.
Intended to let the user longjmp to their own error recovery, if an
error occurs in an unprotected call.
Protected calls so far are only js_newstate, js_dofile and js_dostring.
