Groups and implicit references are no longer relevant at this point.
Also add tests that fail if the first or second round of ephemeral
marking is omitted
BUG=none
R=mstarzinger@chromium.org,hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/761343004
Cr-Commit-Position: refs/heads/master@{#25606}
v8::Object already has GetIdentityHash on it. This change adds its counterpart to v8::Name.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/753373003
Cr-Commit-Position: refs/heads/master@{#25598}
Updates Object.prototype.toString() to use algorithm described in harmony drafts.
Currently, the behaviour is essentially the same as ES262's version, however this changes when internal structures
such as Promise make use of symbolToStringTag (as they are supposed to, see v8:3241), and changes further once
Symbol.toStringTag is exposed publicly.
BUG=v8:3241, v8:3502
LOG=N
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/546803003
Patch from Caitlin Potter <caitpotter88@gmail.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24783 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Since we fill the output buffer both from the chunks and the conversion
buffer, it's possible that we run out of space and call CopyCharsHelper with 0
length. The underlying functions don't handle it gracefully, so check there.
2) There was a bug where we used to try to copy too many characters from the
beginning of the data chunk into the conversion buffer. Continuation bytes in
UTF-8 are of the form 0b10XXXXXX. If a byte is bigger than that, it's the first
byte of a new UTF-8 character and we should ignore it.
These two together (or maybe in combination with surrogates) are a probable
reason for crbug.com/420932.
3) The test data was off; \uc481 is \xec\x92\x81.
BUG=420932
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/662003003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24725 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem was that there can be several multi-byte UTF-8 characters near the
splitting point of the data chunks, and the code didn't handle it properly.
This was also the source of crbug.com/417891 - I thought the crash can only
happen when V8 is passed invalid UTF-8 data, but it can also happen in the
abovementioned case. After the fix, we handle the valid UTF-8 case and also
guard against invalid UTF-8 data.
R=yangguo@chromium.org
BUG=chromium:417891
LOG=N
Review URL: https://codereview.chromium.org/654503002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24547 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
> We also initialize the Isolate on creation.
>
> This should allow for getting rid of the last remaining default isolate
> traces. Also, it'll speed up several isolate related operations that no
> longer require locks.
>
> Embedders that relied on v8::Isolate to return an uninitialized Isolate
> (so they can set ResourceConstraints for example, or set flags that
> modify the way the isolate is created) should either do the setup before
> creating the isolate, or use the recently added CreateParams to pass e.g.
> ResourceConstraints.
>
> BUG=none
> LOG=y
> R=svenpanne@chromium.org
>
> Review URL: https://codereview.chromium.org/469783002
BUG=none
LOG=y
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/583153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We also initialize the Isolate on creation.
This should allow for getting rid of the last remaining default isolate
traces. Also, it'll speed up several isolate related operations that no
longer require locks.
Embedders that relied on v8::Isolate to return an uninitialized Isolate
(so they can set ResourceConstraints for example, or set flags that
modify the way the isolate is created) should either do the setup before
creating the isolate, or use the recently added CreateParams to pass e.g.
ResourceConstraints.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/469783002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24052 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We can only set resource constraints before the isolate is initialized.
Since in the future, we want to initialize isolates at construction
time, we need to set constraints there.
It's possible to later modify the stack limit, so introduce an
Isolate::SetStackLimit method for that.
The SetResourceConstraints method will be deprecated. Users should pass
ResourceConstraints to Isolate::New, and use Isolate::SetStackLimit to
later modify the stack limit.
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/559993005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
several API methods will automatically initialize it. During this
uninitialized state, code event handlers and function entry handlers can
be attached to the isolate.
This CL deprecates SetFunctionEntryHook and moves the configuration of
those handlers to the Isolate factory method.
This will allow for initializing the Isolate at creation time in the
future.
Users of V8::SetFunctionEntryHook should pass the entry hook to
Isolate::New instead. V8::SetJitCodeEventHandler should either be passed
to Isolate::New as well, or (if startup events are not required) invoked
via the Isolate.
BUG=none
LOG=y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/570993002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23940 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
