Reduces dependencies on #include files, making it easier for other
build systems to include this library.
BUG=
Review URL: https://codereview.chromium.org/740493002
Cr-Commit-Position: refs/heads/master@{#25408}
This implements correct semantics for "extensible" top level lexical scope.
The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
When the new script starts executing, it does the following validation:
- checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
- invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
- adds the lexical bindings it introduces to the GlobalContextTable
Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
R=adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/705663004
Cr-Commit-Position: refs/heads/master@{#25220}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>;
R=svenpanne@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/682143003
Patch from Weiliang <weiliang.lin@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
Reason for revert:
It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
Original issue's description:
> Extend CPU profiler with mapping ticks to source lines
>
> The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
> During generation code and relocation info are generated simultaneously.
> When code generation is done you each code object has associated "relocation info".
> Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
> correspondences between the machine program counter and source locations for stack walking.
>
> This patch:
> 1. Add more source positions info in reloc info to make it suitable for source level mapping.
> The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
> (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
> I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
>
> 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
> If a source line is found that hit counter is increased by one for this line.
>
> 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
> Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
>
> 4.Add a test that checks how the samples are distributed through source lines.
> It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
>
> Patch from Denis Pravdin <denis.pravdin@intel.com>
> BUG=None
> LOG=Y
> R=svenpanne@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=24389TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/624443005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>
BUG=None
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/616963005
Patch from Denis Pravdin <denis.pravdin@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since the x64 backend currently doesn't emit ABI compliant code, it is
not possible to unwind the stack. During Win64 SEH this will cause the
exception handling to abort, and not even call the unhandled exception
handler. Embedders are advised to install a custom unwind callback using
RtlInstallFunctionTableCallback for the entire code range to catch
unwind attempts for exception handling.
BUG=v8:3598
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/612043002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24283 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
Add new "Name" type to API that is a supertype of Symbol and String.
Object::SetDeclaredAccessor, Object::SetAccessorProperty, Template::Set,
Template::SetAccessorProperty, and Template::SetDeclaredAccessor now
take a Name as the property name instead of a String.
Add Object::SetAccessor, Template::SetNativeDataProperty, and
ObjectTemplate::SetAccessor overloads that can define accessors for
symbol-named properties.
R=dcarney@chromium.org, rossberg@chromium.org
BUG=v8:3394
TEST=cctest/test-api/TestSymbolProperties
LOG=Y
Review URL: https://codereview.chromium.org/459413002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The bit counting functions provided by CompilerIntrinsics were undefined
for zero, which was easily overlooked and unsafe in general. Also their
implementation was kinda hacky and mostly untested. Fixed the
implementation and moved the functions to base/bits.h.
TEST=base-unittests,cctest,compiler-unittests,mjsunit
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/494633002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23229 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(parser or code) and to be explicit about cache consumption or production
(rather than making presence of cached_data imply one or the other.)
Also add a --cache flag to d8, to allow testing the functionality.
-----------------------------
API change
Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).
Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.
Changes from old behaviour:
- If you previously didn't use caching, nothing changes.
Example:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
- If you previously used caching, it worked like this:
- 1st run:
v8::CompileUnbound(isolate, source, kProduceToCache);
Then, source->cached_data would contain the
data-to-be cached. This remains the same, except you
need to tell V8 which type of data you want.
v8::CompileUnbound(isolate, source, kProduceParserCache);
- 2nd run:
v8::CompileUnbound(isolate, source, kNoCompileOptions);
with source->cached_data set to the data you received in
the first run. This will now ignore the cached data, and
you need to explicitly tell V8 to use it:
v8::CompileUnbound(isolate, source, kConsumeParserCache);
-----------------------------
BUG=
R=marja@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/389573006
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
During https://code.google.com/p/v8/source/detail?r=19925 checkin context bound scripts (Script)
and context unbound scripts (UnboundScript) are Distinguished.
And then Sven Panne helped to fix the vtune support compilation
error in https://code.google.com/p/v8/source/detail?r=20955.
The problem is that there is runtime error for vtune
support.
In our original implementation, we encapsulated and passed v8::internal::Script
to V8 API. It will leads to type check error for current V8::Script definition.
So I changed the Handle<Script> definition in JitCodeEvent
to Handle<UnboundScript>
and add the corresponding change in log.cc.
If you do NOT prefer to change in include/v8.h. I think I can change the definition of
CodeEventLogger::LogRecordedBuffer(...) so that the we can pass the correct
type (JSFunction) as V8::Script to V8 API.
BUG=
R=danno@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/334263018
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22393 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The callbacks are per isolate, so we shouldn't get the isolate implicitly
from TLS. Also, we shouldn't allow calls to these methods prior to
initializing the respective isolate (and silently ignore them).
Esp. add a per-isolate API to set the stats counter callbacks and
make it possible to set the stats counter callback after the isolate
was touched.
Embedders should use e.g. isolate->SetCounterFunction(callback) instead
of v8::V8::SetCounterFunction(callback).
BUG=none
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/365153002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22223 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
[Re-retry of r21696 and r21739]
If the embedder chooses, the 'natives' (library sources) and the
precompiled startup blob can be written to files during the build
process and handed over to V8 at startup. The main purpose would be
to reduce the size of the compiled binary for space constrained
platforms.
The build-time option is off by default. Nothing should change if
it's not enabled.
BUG=
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/334913004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
[Retry of crrev.com/293993021, which caused problems with 'ninja all' in Chromium. First patch set if a clean apply
of crrev.com/293993021. Subsequent sets are the actual fix
for that issue.]
If the embedder chooses, the 'natives' (library sources) and the
precompiled startup blob can be written to files during the build
process and handed over to V8 at startup. The main purpose would be
to reduce the size of the compiled binary for space constrained
platforms.
The build-time option is off by default. Nothing should change if
it's not enabled.
BUG=
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/315033002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21696 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the embedder chooses, the 'natives' (library sources) and the
precompiled startup blob can be written to files during the build
process and handed over to V8 at startup. The main purpose would be
to reduce the size of the compiled binary for space constrained
platforms.
The build-time option is off by default. Nothing should change if
it's not enabled.
BUG=
R=bmeurer@chromium.org, jochen@chromium.org
Review URL: https://codereview.chromium.org/293993021
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21646 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
v8::DontDelete is set for Unforgeable properties, so just not setting PROHIBITS_OVERWRITING should be enough.
The secondary "feature" of not allowing accessors to be installed in extending objects is incorrect and confusing, given that it only applies to accessors but not to regular properties:
Object.defineProperty({__proto__:window}, "location", { value: 10 })
works where
Object.defineProperty({__proto__:window}, "location", { get: function() {} })
doesn't work.
LOG=y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/306203002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21596 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If the embedder calls V8::TerminateExecution while we're running microtasks, bail out
and clear any pending microtasks.
All other exceptions are simply swallowed. No current Blink or V8 microtasks throw, this
just ensures something sane happens if another embedder decides to pass a throwing
microtask (or if ours unexpectedly throw due to, e.g., stack exhaustion).
BUG=371566
LOG=Y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/294943009
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21574 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
[2nd try, after the previous version broke the build]
Currently, this code will compile:
SomePointer* p = ...;
ReturnValue r = ...;
r.Set(p);
What happens is that ReturnValue::Set has no pointer-ish overloads, but
a bool one, and hence C++ will convert the pointer to a bool and use
the Set(bool) overload. In other words, the example above is equivalent
to: r.Set(p ? true : false); Which probably isn't what the author had
in mind. This change adds a Set(void*) overload whose body forces a
compile error, to prevent this from happening inadvertently. The only
use of this indeed turned out to be an error.
(Said error was fixed/removed in crrev.com/267393002.)
Why was crrev.com/240013004 reverted?
The orginal version compiled fine on gcc (+ MSVC), but not on clang.
There's no clang try-bots, but the ASAN-based buildbots used clang
and hence the build broke. I'm slightly unsure on why, but clang -
unlike those other compilers - eagerly compiled the non-compilable
setter, which predictably broke. Now, the non-compilable setter uses
the same template logic that all other, comparable cases use. I've
tried 'make qc' with both gcc and clang versions.
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/279883002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21228 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reason for revert:
Looks like this broke the "V8 Linux64 ASAN" build.
Original issue's description:
> Prevent calls to ReturnValue::Set with pointer-valued types.
>
> Currently, this code will compile:
> SomePointer* p = ...;
> ReturnValue r = ...;
> r.Set(p);
>
> What happens is that ReturnValue::Set has no pointer-ish overloads, but
> a bool one, and hence C++ will convert the pointer to a bool and use
> the Set(bool) overload. In other words, the example above is equivalent
> to: r.Set(p ? true : false); Which probably isn't what the author had
> in mind. This change adds a Set(void*) overload whose body forces a
> compile error, to prevent this from happening inadvertently. The only
> use of this indeed turned out to be an error.
>
> (Said error was fixed/removed in crrev.com/267393002.)
>
> BUG=
> R=dcarney@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=21217R=ishell@chromium.org
Review URL: https://codereview.chromium.org/271113002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently, this code will compile:
SomePointer* p = ...;
ReturnValue r = ...;
r.Set(p);
What happens is that ReturnValue::Set has no pointer-ish overloads, but
a bool one, and hence C++ will convert the pointer to a bool and use
the Set(bool) overload. In other words, the example above is equivalent
to: r.Set(p ? true : false); Which probably isn't what the author had
in mind. This change adds a Set(void*) overload whose body forces a
compile error, to prevent this from happening inadvertently. The only
use of this indeed turned out to be an error.
(Wait for issue 364025 before submitting.)
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/240013004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21217 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use the surrounding map (instead of Traits::Impl) for weak callback.
- Provide for a fast reference to a mapped value.
- Restructure Traits to accomondate for the first point above.
[Why?] As discussed, I proceeded to replace Impl with the map.
The problem I encountered with that version is that now the
Traits class depends on itself: The weak-related methods require the
map type in their signature. But the map type includes the Traits class
and hence the Traits class method signatures depend on the specific Traits class. That
makes them practically un-derivable: While you can derive a Traits class
from another one, since the compiler now expects methods with a different
signature. To accommodate, I pulled the dispose traits into the weak traits
class. I also removed the Impl*/MapType* parameter from the Dispose call,
since no implementation seems to need it.
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/212893007
Patch from Daniel Vogelheim <vogelheim@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
This is a fixed version of https://codereview.chromium.org/186723005/
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/199063003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/186723005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19881 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is preparatory work to get rid of UnsafePersistent in blink.
The previous version had to be reverted due to timeouts in win32/Debug: https://codereview.chromium.org/197173002/
The timeouts happened because the STL version on that platform contains sanity checking code which opens a 'debug window' in the GUI, patiently waiting for the user to click ok/cancel/somethirdoption. It turns out, the cause for that debug window was totally valid and the test had a use-after-free issue.
The 1st patch set is the code as before. The 2nd patch set contains the fix.
Related blink changes are here: https://codereview.chromium.org/180363004/
This patch is largely based on https://codereview.chromium.org/175503003/, with some methods added to support the blink change mentioned above.
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/197263002
Patch from Daniel Vogelheim <vogelheim@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This feature makes it possible to associate data with a script and get it back
when the script is compiled or when an event is handled. It was historically
used by Chromium Dev Tools, but not any more. It is not used by node.js.
Note: this has nothing to do with the preparse data, despite the confusing name.
The preparse data is passed as ScriptData*.
Note 2: This is the same as r19616 ( https://codereview.chromium.org/184403002/ )
with a unused variable fix in bootstrapper.cc.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/185533014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19702 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This feature makes it possible to associate data with a script and get it back
when the script is compiled or when an event is handled. It was historically
used by Chromium Dev Tools, but not any more. It is not used by node.js.
Note: this has nothing to do with the preparse data, despite the confusing name.
The preparse data is passed as ScriptData*.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/184403002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch generalizes Object.observe callbacks and promise resolution into a FIFO queue called a "microtask queue".
It also exposes new V8 API which exposes the microtask queue to the embedder. In particular, it allows the embedder to
-schedule a microtask (EnqueueExternalMicrotask)
-run the microtask queue (RunMicrotasks)
-control whether the microtask queue is run automatically within V8 when the last script exits (SetAutorunMicrotasks).
R=dcarney@chromium.org, rossberg@chromium.org, dcarney, rossberg, svenpanne
BUG=
Review URL: https://codereview.chromium.org/154283002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=danno@chromium.org, mstarzinger@chromium.org
LOG=N
BUG=
Committed: https://code.google.com/p/v8/source/detail?r=18918
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
mostly to make sure that it is going in the right direction. The current
version is passing all the existing test + a bunch of new tests
(packaged in the change list, too).
The patch extends the SlotRef object to describe captured and duplicated
objects. Since the SlotRefs are not independent of each other anymore,
there is a new SlotRefValueBuilder class that stores the SlotRefs and
later materializes the objects from the SlotRefs.
Note that unlike the previous implementation of SlotRefs, we now build
the SlotRef entries for the entire frame, not just the particular
function. This is because duplicate objects might refer to previous
captured objects (that might live inside other inlined function's part
of the frame).
We also need to store the materialized objects between other potential
invocations of the same arguments object so that we materialize each
captured object at most once. The materialized objects of frames live
in the new MaterielizedObjectStore object (contained in Isolate),
indexed by the frame's FP address. Each argument materialization (and
deoptimization) tries to lookup its captured objects in the store before
building new ones. Deoptimization also removes the materialized objects
from the store. We also schedule a lazy deopt to be sure that we always
get rid of the materialized objects and that the optmized function
adopts the materialized objects (instead of happily computing with its
captured representations).
Concerns:
- Is there a simpler/more correct way to store the already-materialized
objects? (At the moment there is a custom root reference to JSArray
containing frames' FixedArrays with their captured objects.)
- Is the FP address the right key for a frame? (Note that deoptimizer's
representation of frame is different from the argument object
materializer's one - it is not easy to find common ground.)
- Performance is suboptimal in several places, but a quick local run of
benchmarks does not seem to show a perf hit. Examples of possible
improvements: smarter generation of SlotRefs (build other functions'
SlotRefs only for captured objects and only if necessary), smarter
lookup of stored materialized objects.
- Ideally, we would like to share the code for argument materialization
with deoptimizer's materializer. However, the supporting data structures
(mainly the frame descriptor) are quite different in each case, so it
looks more like a separate project.
Thanks for any feedback.
R=mstarzinger@chromium.org, danno@chromium.org
LOG=N
BUG=
Review URL: https://codereview.chromium.org/103243005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18918 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch makes String::WriteUtf8 replace invalid code points (i.e. unmatched
surrogates) with the unicode replacement character when REPLACE_INVALID_UTF8 is
set. This is done to avoid creating invalid UTF-8 output which can lead to
compatibility issues with software requiring valid UTF-8 inputs (e.g. the
WebSocket protocol requires valid UTF-8 and terminates connections when invalid
UTF-8 is encountered).
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/121173009
Patch from Felix Geisendörfer <haimuiba@gmail.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
