(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
- 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
This is done similar to weak embedded objects in optimized code (r17102). The
reference from optimized code to a cell is treated weakly in marking visitors
if the cell points to a JSObject. After marking we iterate over all cells
embedded in optimized code. If a cell is not marked but its value is marked,
then we revive the cell by marking it. Otherwise, the cell value is dead, so
we mark the code for deoptimization.
BUG=v8:2073
TEST=cctest/test-heap/CellsInOptimizedCodeAreWeak
LOG=Y
R=hpayer@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/117483002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It's of much use when information about function calls is shown on the Events timeline in DevTools: instead of referencing to v8natives.js where bound functions are created, we'll be able to show real function data (name, resource, script line and column numbers) retrieved from original functions.
BUG=None
LOG=Y
R=yangguo@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/106763002
Patch from Alexandra Mikhaylova <amikhaylova@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18401 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
