Only create an iterator for coercible types in OP_ITERATOR, and then
detect the lack of a real iterator in OP_NEXTITER.
Thus we don't need to allocate and push an empty iterator object for
these cases.
Reduce memory use per property by not keeping the properties in two
parallel data structures. Maintaining the order of insertion is not
required by the spec, and is not a very useful feature.
Make sure to make a copy of the source pattern string.
A case we missed when adding short and memory strings to the runtime.
The code assumed all strings passed to it were either literal or interned.
When a userdata object is garbage collected, we should invoke a callback
to client code to let it know that the associated userdata pointer is no
longer in use.
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.
Any coercion between types may overwrite the stack slot with the coerced
value. This is usually not a problem, but if you need to preserve the
original value, you should copy it to another stack slot before running
any functions that may coerce the type (anything involving ToPrimitive).
This change lets us avoid interning the result of toString().
If we later add short strings (embedded in js_Value and js_Property
structs) then we can also avoid creating a garbage collected string or
interning the result of js_tostring on a number.
Separate literal/interned and garbage collected string types in js_Value.
js_pushintern/js_tointern are convenience functions to push/pop strings and
automatically intern them (so that the string pointers are guaranteed to be
stable).
js_pushliteral should push stable strings (either interned or actual literals).
js_pushstring will copy the string into garbage collected memory.
The pointer returned by js_tostring is guaranteed to be stable only for as long as
the stack slot it came from remains untouched.
Some uses will always cause a string to be interned:
* Using it as a property name.
* Wrapping it in a new String() object.
* Strings returned by toString().
ToPrimitive must not clobber the stack, so the result has to be unrooted.
* Numbers converted to strings (by js_tostring)
Likewise, we have nowhere to store the temporary string here.
Passing in a scratch buffer to js_tostring could help this problem.
Mostly an issue with array accesses (OP_GETPROP, etc) so an auxiliary
function and we don't have to clutter the API needlessly.
The tail pointer in the linked list head was mismanaged, leading
to using free memory when properties are inserted after deleting
a property such that the tail points to the deleted node.
Follow the spec more strictly, and don't rely on strtod's grammar.
GNU libc strtod accepts 0x prefixes, INF, INFINITY and much more which
we don't want, so pre-filter the string we pass to strtod.
js_newuserdata(J, tag, ptr) creates a userdata object, wrapping the ptr.
It takes the prototype for the new object from the top of the stack, just
like js_newcconstructor does.
js_touserdata(J, tag, idx) extracts the userdata pointer. Throws a
TypeError if the object is not a userdata object with a matching tag.
js_isuserdata(J, tag, idx) checks if a value on the stack is a userdata
object with a matching tag.
