This reverts commit 24aca87090.
The API makes these values appear to be per-isolate, when in fact
they are per-context. Installing the results of these on Template
objects instantiated in multiple contexts can result in security
violations and contexts being retained indefinitely.
An alternative mechanism for using these in a sensible way is
provided by https://crrev.com/1409593002
BUG=
LOG=N
R=jochen@chromium.org, adamk@chromium.org
Review URL: https://codereview.chromium.org/1415663002
Cr-Commit-Position: refs/heads/master@{#31417}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg,v8_linux_gcc_rel
Review URL: https://codereview.chromium.org/1393023003
Cr-Commit-Position: refs/heads/master@{#31185}
Reason for revert:
Breaks Arm debug.
Original issue's description:
> Reland: Introduce a V8_NORETURN macro and use it to make GCC 4.9.2 happy again.
>
> Without that, it has a few false positives about out-of-bounds array accesses.
> Also makes the clang static-analyzer happy.
>
> Original code review from Sven Panne:
> https://codereview.chromium.org/790723002/
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg
>
> Committed: https://crrev.com/93ae81101af68d81b7af84ea4046ea849e605116
> Cr-Commit-Position: refs/heads/master@{#31163}
TBR=jochen@chromium.org,karl@skomski.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1398643002
Cr-Commit-Position: refs/heads/master@{#31167}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg
Review URL: https://codereview.chromium.org/1383053005
Cr-Commit-Position: refs/heads/master@{#31163}
Allow access to Array Iterator through the API, in order to simplify
setting up interfaces which use these methods. This applies to
WebIDL interfaces with "length" attributes returning integer types and
a getter taking an unsigned long type.
BUG=
LOG=N
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1378403004
Cr-Commit-Position: refs/heads/master@{#31152}
Symbols marked as "well-known" now return an undefined value when loaded with a failed access check, instead of throwing.
Currently, only @@isConcatSpreadable is marked as well-known, until the correct behaviour is properly specified.
BUG=v8:4289, 507553
LOG=N
R=adamk@chromium.org, jochen@chromium.org, verwaest@chromium.org
Review URL: https://codereview.chromium.org/1230793002
Cr-Commit-Position: refs/heads/master@{#31131}
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg
Review URL: https://codereview.chromium.org/1384873002
Cr-Commit-Position: refs/heads/master@{#31105}
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1371083003
Cr-Commit-Position: refs/heads/master@{#31019}
This prevents the internal incremental-marking.h to be usable outisde
of the "heap" directory. The logic inside that component is only useful
within the GC and is now properly encapsulated.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1374203002
Cr-Commit-Position: refs/heads/master@{#31010}
Reason for revert:
This CL breaks cross-compiling to arm.
Original issue's description:
> Introduce a V8_NORETURN macro and use it to make GCC 4.9.2 happy again.
>
> Without that, it has a few false positives about out-of-bounds array accesses.
> Also makes the clang static-analyzer happy.
>
> Original code review from Sven Panne:
> https://codereview.chromium.org/790723002/
>
> Committed: https://crrev.com/0b48b2a8ebfc791a36f4ec1f299f46db76265a3a
> Cr-Commit-Position: refs/heads/master@{#30977}
TBR=jochen@chromium.org,bmeurer@chromium.org,jkummerow@chromium.org,karl@skomski.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1370203002
Cr-Commit-Position: refs/heads/master@{#30982}
This enables the general linter checking for "build/c++11" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/1317463007
Cr-Commit-Position: refs/heads/master@{#30621}
This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
let x = 1;
function f(g = () => x) {
var y
eval("var x = 2")
return g() + x // f() = 3
}
we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
- Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
- When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
- While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
- Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
- Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
- In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
- In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
- ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
- Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
- While at it, refactor and unify some respective code in the debugger.
Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
@mstarzinger: Please review the changes to contexts.
@yangguo: Please have a look at the debugger stuff.
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:811,v8:2160
LOG=N
Review URL: https://codereview.chromium.org/1292753007
Cr-Commit-Position: refs/heads/master@{#30295}
* Add types to properly report what has been executed in the GC
* Unify GCPrologueCallback and GCEpilogueCallback into GCCallback
* Report processing of second round weak handels, either synchronously or asynchronously
BUG=chromium:521946
LOG=N
Review URL: https://codereview.chromium.org/1298113003
Cr-Commit-Position: refs/heads/master@{#30218}
- Make the API look like v8::V8::InitializeICU.
(That is: A static method call, not an object to be created on the stack.)
- Fix path separator on Windows, by calling base::OS::isPathSeparator.
- Move into API, so that it can be called by hello-world & friends.
- Actually call it from hello-world and friends.
R=jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1292053002
Cr-Commit-Position: refs/heads/master@{#30174}
Improves on aec8987b5e by not forcing external GCs
(blink) through the GC epilogue callback.
BUG=chromium:515795
LOG=N
Review URL: https://codereview.chromium.org/1287323002
Cr-Commit-Position: refs/heads/master@{#30164}
First step to simplify the TypeofStub. This is similar to the
optimization that we use for ToNumber and ToString on Oddballs already.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1272763005
Cr-Commit-Position: refs/heads/master@{#30108}
There's no need to have one InstanceType per SIMD primitive type (this
will not scale long-term). Also reduce the amount of code duplication
and make it more robust wrt adding new SIMD types.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1273353003
Cr-Commit-Position: refs/heads/master@{#30107}
No need to provide TO_INT32/TO_UINT32 functions for every native
context, as they can be implemented in terms of TO_NUMBER more easily
and efficiently.
Also remove the obsolete TO_BOOLEAN_FUN_INDEX from the native contexts.
Review URL: https://codereview.chromium.org/1275013004
Cr-Commit-Position: refs/heads/master@{#30080}
This is only an estimate since it counts objects that could be shared,
for example strings, cow arrays, heap numbers, etc.
It however ignores objects that could be shared, but may only be used
by the context to be measured, for example shared function infos,
script objects, scope infos, etc.
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/1268333004
Cr-Commit-Position: refs/heads/master@{#30029}
There is only one use case for it: String.prototype.search converts a
string argument into a RegExp. The cache is used to avoid repeating that
conversion. However, this does not make the added complexity worthwhile.
Review URL: https://codereview.chromium.org/1267493006
Cr-Commit-Position: refs/heads/master@{#29985}
This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL). For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject. Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.
R=mvstanton@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1266013006
Cr-Commit-Position: refs/heads/master@{#29953}
This is required in order for Globals to be stored in STL containers.
Patch from Aaron Link <aaronlink@google.com>
BUG=
Review URL: https://codereview.chromium.org/1244033002
Cr-Commit-Position: refs/heads/master@{#29776}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
These were added when I thought they would be useful in Blink, but as
it turned out they were not. They could likely be deleted immediately,
but to play it safe I'll go through the usual deprecation process.
Review URL: https://codereview.chromium.org/1236263004
Cr-Commit-Position: refs/heads/master@{#29690}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
The CL addes convenienve method that allows to write code like the following
v8::Local<v8::Object> local = v8::Local<v8::Object>::New(global, isolate);
in a more readable way:
v8::Local<v8::Object> local = global.Get(isolate);
There is already v8::Eternal::Get that does similar thing.
BUG=None
LOG=Y
Review URL: https://codereview.chromium.org/1237603003
Cr-Commit-Position: refs/heads/master@{#29616}
The only right way to enable access checks is to install access check callbacks on an object template via v8::ObjectTemplate::SetAccessCheckCallbacks(). It does not make sense to enable access checks on an arbitrary object.
Review URL: https://codereview.chromium.org/1217893012
Cr-Commit-Position: refs/heads/master@{#29439}
Map: get, set, has, delete, clear
Set: add, has, delete, clear
All except clear are implemented as calls into collection.js.
Note that some of these shadow methods of v8::Object. It's unclear
how confusing that's going to be: on the one hand, it seems likely
that most operations you would want to do on a Map or Set are these.
On the other, generic code could get confused if it somehow gets
ahold of a variable that happens to be C++-typed as a v8::Map or v8::Set.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1204623002
Cr-Commit-Position: refs/heads/master@{#29237}
Delayed tasks can be used to perform non-urgent clean up work.
BUG=chromium:490559
LOG=NO
Review URL: https://codereview.chromium.org/1179153002
Cr-Commit-Position: refs/heads/master@{#29084}
Up until now we used int32_t for NodeId, but that was not ideal because
negative values are invalid for NodeId and we use it as an array index
for example in the NodeMarker class, where C++ compilers on x64 have to
generate code that does proper sign extension for the indices, which is
completely unnecessary.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1178403004
Cr-Commit-Position: refs/heads/master@{#28997}
Embed constant pools within their corresponding Code
objects.
This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.
Currently supported on PPC and ARM. Enabled by default on
PPC only.
This yields a 6% improvment in Octane on PPC64.
R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y
Review URL: https://codereview.chromium.org/1162993006
Cr-Commit-Position: refs/heads/master@{#28801}
This will significantly simplify the serialization code, as well
as speeding it up (by triggering only a single allocation instead of O(size)
allocations).
BUG=chromium:478263
LOG=y
Review URL: https://codereview.chromium.org/1157843006
Cr-Commit-Position: refs/heads/master@{#28793}
These are similar to the Map/Set constructors when called with an array,
except that they are guaranteed to be side-effect free if called with
a packed array.
This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1155893003
Cr-Commit-Position: refs/heads/master@{#28642}
These return arrays representing the current contents of the given
Map/Set. They are similar to what would be returned by the JS code:
Array.from(collection)
except that they are guaranteed side-effect free.
This will be useful in implementing structured clone which, as
specified in HTML, speaks in terms of the internal [[MapData]]
and [[SetData]] slots without going through the exposed iteration
ES semantics.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1148383007
Cr-Commit-Position: refs/heads/master@{#28640}
Only supports constructing new objects and returning size.
Followup patch will need to add ability to retrieve and
set contents in order to support structured clone.
Also removes a bunch of outdated "experimental" markers from v8.h.
BUG=v8:3340
LOG=y
Review URL: https://codereview.chromium.org/1157453002
Cr-Commit-Position: refs/heads/master@{#28637}
(Requires the embedder's ExternalSourceStream implementation to cooperate.
See crrev.com/1154883003 for Blink.)
R=jochen@chromium.org
BUG=chromium:470930
LOG=Y
Review URL: https://codereview.chromium.org/1156733002
Cr-Commit-Position: refs/heads/master@{#28610}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
This macro is used for defining static data members with
STATIC_CONST_MEMBER_DEFINITION. Clang-cl mimics MSVC's
behaviour here, so it also needs __declspec(selectany).
This change was prompted by Clang r237787 which changed
a bug where Clang would previously not emit symbols for
some static data members.
BUG=82385
LOG=N
Review URL: https://codereview.chromium.org/1145213004
Cr-Commit-Position: refs/heads/master@{#28563}
This should help to keep syntax errors from creeping into v8.h
Also, I'll remove usages of to-be-deprecated APIs and turn this flag on
for standalone builds
BUG=4134
R=vogelheim@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1149633003
Cr-Commit-Position: refs/heads/master@{#28538}
For dumping the number of objects and size of objects alive after the
last gc into chrome://tracing memory dumps, this CL adds new api to
get these number for each isolate.
Note: Chrome should be run with --js-flags='--track_gc_object_stats
--noincremental-marking' for object tracking.
BUG=476013
LOG=Y
Review URL: https://codereview.chromium.org/1113233002
Cr-Commit-Position: refs/heads/master@{#28474}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Committed: https://crrev.com/7a599c5e1242d3c5ab7515ee149623da90ae69ec
Cr-Commit-Position: refs/heads/master@{#28445}
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28459}
When the page is controlled by a ServiceWorker, the ServiceWorker can return an opaque (non-CORS cross origin) resource response.
We need to treat the messages from such script resource as opaque.
Review URL: https://codereview.chromium.org/1140673002
Cr-Commit-Position: refs/heads/master@{#28445}
Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
BUG=chromium:481845
LOG=Y
Review URL: https://codereview.chromium.org/1134193002
Cr-Commit-Position: refs/heads/master@{#28371}
Reason for revert:
GC mole issues: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gcmole/builds/1950/steps/GCMole%20ia32/logs/stdio
Original issue's description:
> Provide accessor for object internal properties that doesn't require debugger to be active
>
> Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
>
> Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
>
> BUG=chromium:481845
> LOG=Y
>
> Committed: https://crrev.com/bdeb0de88c8cf5f2c78f261b45314138f525110d
> Cr-Commit-Position: refs/heads/master@{#28362}
TBR=pfeldman@chromium.org,kozyatinskiy@chromium.org,yurys@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:481845
Review URL: https://codereview.chromium.org/1133243002
Cr-Commit-Position: refs/heads/master@{#28365}
Some of the DevTools' clients need to inspect JS objects without enabling debugger. This CL allows to inspect object's internal properties without enabling debugger and instantiating debug context.
Note that now debug context can be created lazily if v8::Debug::GetDebugContext is called when there is no debug listener. This is fragile and has already resulted in some subtle error. I'm going to fix that in a separate CL.
BUG=chromium:481845
LOG=Y
Review URL: https://codereview.chromium.org/1126103006
Cr-Commit-Position: refs/heads/master@{#28362}
If there had been no debug listener v8::Debug::GetDebugContext would have created new context and wouln't have kept reference to it. This way we may well end up with several debug contexts and disabled debugger.
As a side effect this change allows to efficiently distinguish debug context from blink contexts by simply comparing handles.
BUG=chromium:482290
LOG=Y
Review URL: https://codereview.chromium.org/1136733002
Cr-Commit-Position: refs/heads/master@{#28356}
Exposed to the extras as extrasExports (on the builtins object), on
which they can put things that should be accessible from C++. Exposed
to C++ through the V8 API as v8::Context::GetExtrasExportsObject().
Adding a test (in test-api.cc) required adding a simple extra,
test-extra.js, which we build into the standalone builds.
R=yangguo@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1128113006
Cr-Commit-Position: refs/heads/master@{#28317}
I know the bug has been closed but this seems like a simple addition that may
be useful in other ways as well.
BUG=v8:2180
LOG=N
Review URL: https://codereview.chromium.org/1128553002
Cr-Commit-Position: refs/heads/master@{#28261}
These macros are not needed anymore, so there's no point in supporting
them.
Review URL: https://codereview.chromium.org/1123723003
Cr-Commit-Position: refs/heads/master@{#28214}
Just give internal ones an ArrayBuffer with a NULL backing store. This
simplifies the access checks a lot.
BUG=v8:3996
R=hpayer@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1109353003
Cr-Commit-Position: refs/heads/master@{#28168}
We shouldn't have shared state between isolates by default. The embedder
is free to pass the same allocator to all isolates it creates.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1116633002
Cr-Commit-Position: refs/heads/master@{#28127}
For dumping memory statistics about v8 heap, we need the total
available size of the heap. This CL adds extra field in HeapStatistics
to return the available size.
BUG=476013
LOG=Y
Review URL: https://codereview.chromium.org/1104123002
Cr-Commit-Position: refs/heads/master@{#28100}
The embedder has to take appropriate steps to ensure that the
ArrayBuffer doesn't die while it's accessing the pointer, e.g. keep a
Local handle to it around
BUG=none
R=dslomov@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1095083002
Cr-Commit-Position: refs/heads/master@{#27942}
This class was added in crrev.com/1058253003 and missed V8_EXPORT in
definition.
BUG=466141, 476013
LOG=Y
Review URL: https://codereview.chromium.org/1090333002
Cr-Commit-Position: refs/heads/master@{#27926}
This is first step towards adding V8 heap statistics to the memory
tracing infrastructure. For being able to get useful memory number into
the memory dump, v8 needs to provide an external api needs to obtain
more information about the heap. So, this Cl extends the api to give
information about the memory allocated and used in the spaces.
BUG=466141, 476013
LOG=Y
Review URL: https://codereview.chromium.org/1058253003
Cr-Commit-Position: refs/heads/master@{#27919}
The embedder can control how many threads it wants to use via the
v8::Platform implementation. V8 internally doesn't spin up threads
anymore. If the embedder doesn't want to use any threads at all, it's
v8::Platform implementation must either run the background jobs on
the foreground thread, or the embedder should specify --predictable
BUG=none
R=yangguo@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1064723005
Cr-Commit-Position: refs/heads/master@{#27833}
As uClibc defines __GLIBC__ in an attempt to look like glibc, V8_LIBC_GLIBC
was true for uClibc as well. Checking for uClibc before glibc fixes this
and restores the correct behavior.
BUG=
Review URL: https://codereview.chromium.org/1066573005
Cr-Commit-Position: refs/heads/master@{#27806}
This allows the embedder to decide whether it's worthwhile to copy the
contents to avoid materializing a buffer.
BUG=v8:3996
R=dslomov@chromium.org,kbr@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1084513002
Cr-Commit-Position: refs/heads/master@{#27782}
When debugging Handle leaks in io.js we found it very convenient to be
able to Seal some specific (root in our case) scope to prevent Handle
allocations in it, and easily find leakage.
R=yangguo
BUG=
Review URL: https://codereview.chromium.org/1079713002
Cr-Commit-Position: refs/heads/master@{#27766}
gcc rejects the following snippet, clang rejects it in -std=c++11 mode:
namespace A { template<class T> class C {}; }
namespace B { template class A::C<int>; }
Indeed, the C++ standard says in 14.7.2p2 "An explicit instantiation shall
appear in an enclosing namespace of its template", so cl.exe is incorrect to
allow this.
Just move the instantiation out of the v8 namespace to fix. No intended
behavior change. Fixes building with clang-cl on Windows.
BUG=chromium:475643
LOG=N
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1073903002
Cr-Commit-Position: refs/heads/master@{#27721}
Reason for revert:
Causes test failures on ARM bots related to cells and write barriers.
Original issue's description:
> Merge cellspace into old pointer space
>
> BUG=
>
> Committed: https://crrev.com/4e7163ce05f135918205c7855ae60a48e5d46cc5
> Cr-Commit-Position: refs/heads/master@{#27707}
TBR=hpayer@chromium.org,balazs.kilvady@imgtec.com,yangguo@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1053243003
Cr-Commit-Position: refs/heads/master@{#27711}
Instead, please use v8::Isolate::RequestInterrupt to synchronize
to the main thread.
R=yurys@chromium.org
API=Removed v8::Debug::DebugBreakForCommand
LOG=Y
Review URL: https://codereview.chromium.org/1036863002
Cr-Commit-Position: refs/heads/master@{#27625}
The motivation is that we prefer to avoid creating internal properties, and we have a usable field on maps ("transitions", which is not used for prototype maps).
This CL also ensures the invariant that prototype maps are never shared, even if they are in dictionary mode.
Review URL: https://codereview.chromium.org/1033653002
Cr-Commit-Position: refs/heads/master@{#27617}
It triggers once per context that calls observe (or attempts to access
any observation metadata, e.g. through Object.getNotifier).
Review URL: https://codereview.chromium.org/1048213002
Cr-Commit-Position: refs/heads/master@{#27557}
Before this patch the embedder could assign timestamp to the last interval after calling GetHeapStats. This would be slightly different from the timstamps assigned by v8 internally and written into heap snapshot. This patch allow to avoid this small discrepancy by returning timestamp along with last heap stats update.
BUG=chromium:467222
LOG=Y
Review URL: https://codereview.chromium.org/1037803002
Cr-Commit-Position: refs/heads/master@{#27466}
If the Maybe is nothing or the MaybeLocal is empty, it means that the
API call either threw an exception or an exception was already pending.
In that case, the embedder needs to handle the exception or otherwise
react to the failed API call.
BUG=v8:3929
R=svenpanne@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1022803002
Cr-Commit-Position: refs/heads/master@{#27298}
Some native counters (e.g. KeyedLoadGenericSlow) are referenced from stubs that are generated very early in the Isolate lifecycle before v8::Isolate::New returns. Thus counter lookup callback also needs to be installed early prior to v8::internal::Isolate::Init call. Otherwise assembler will just assume that the counter is not enabled and produce no code from IncrementCounter - because address of the counter is not yet available.
Histogram related callbacks are moved for consistency to make them able to collect samples which occur at isolate initialization time.
BUG=
Review URL: https://codereview.chromium.org/1010233002
Cr-Commit-Position: refs/heads/master@{#27262}
It should be possible to cast a Value to Int32 without throwing an exception
when IsInt32() is true. Same for Uint32.
BUG=chromium:462402
LOG=Y
Review URL: https://codereview.chromium.org/1003663002
Cr-Commit-Position: refs/heads/master@{#27156}
This removes the separate tracking of the pending message script,
because that script is already stored in the message object and
duplicating it in the ThreadLocalTop makes it more brittle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/995013005
Cr-Commit-Position: refs/heads/master@{#27127}
We should be able to cast a Value to Boolean when IsBoolean() is true.
Review URL: https://codereview.chromium.org/990943003
Cr-Commit-Position: refs/heads/master@{#27124}
None of these fields is used in Blink. Embedder always can implement them using existing API.
BUG=chromium:465651
LOG=Y
Review URL: https://codereview.chromium.org/983833006
Cr-Commit-Position: refs/heads/master@{#27113}
This makes sure that the pending message location is only tracked by
the message object, as only this is saved for finally-blocks. The
location information is duplicated and becomes stale.
R=titzer@chromium.org
TEST=maeh, not so much.
Review URL: https://codereview.chromium.org/987353002
Cr-Commit-Position: refs/heads/master@{#27109}
since the old style weakness is slated for removal, we might as well reuse the name to limit confusion. additionally I simplified the callback type to a enum to either get internal field values or not
this should be a non-breaking change with the exception of PhantomPersistentValueMap, which is unused.
R=jochen@chromium.org, erikcorry@chromium.org
BUG=
Review URL: https://codereview.chromium.org/989153003
Cr-Commit-Position: refs/heads/master@{#27084}
This keeps dying maps alive for FLAG_retain_maps_for_n_gc garbage collections
to increase chances of them being reused for new objects in future and
decrease number of deoptimizations.
BUG=v8:3664
LOG=N
TEST=cctest/test-heap/MapRetaining
Review URL: https://codereview.chromium.org/980523004
Cr-Commit-Position: refs/heads/master@{#27040}
According to Source Map specification [1] source map url can be passed either as a magic comment at the end of script or as SourceMap http header. We already parse the former value and expose it on Script object. This change allows to unify the way we deal with source map urls received in http header by providing api for passing that url into the script being compiled.
source_map_url is intentionally not passed into CompilationCacheScript::Lookup. The cache is anyways disabled when debugger is on.
[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
LOG=Y
BUG=chromium:462572
Review URL: https://codereview.chromium.org/983603003
Cr-Commit-Position: refs/heads/master@{#27017}
Side note: tools/v8-info.sh seems to have been broken ever
since the move to git. At least it's not more broken now.
BUG=v8:3075
LOG=y
TEST=./script_test.py
Review URL: https://codereview.chromium.org/959713003
Cr-Commit-Position: refs/heads/master@{#26873}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/900123003
Cr-Commit-Position: refs/heads/master@{#26451}
When embedder detaches the global objects, its context must be garbage
collected eventually.
BUG=
Review URL: https://codereview.chromium.org/898663005
Cr-Commit-Position: refs/heads/master@{#26450}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/891473005
Cr-Commit-Position: refs/heads/master@{#26425}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/886473005
Cr-Commit-Position: refs/heads/master@{#26401}
When --vector-ics is true, we still tail-call to the hand-written
megamorphic KeyedLoadIC (formerly "generic"). Now that this code uses
the megamorphic cache, it needs to deal properly with the vector and
slot registers. Achieve this with a sentinel vectors/slot combo.
R=dcarney@chromium.org
BUG=
Review URL: https://codereview.chromium.org/892173002
Cr-Commit-Position: refs/heads/master@{#26381}
Contribution of PowerPC port (continuation of 422063005 and 817143002). This patch covers
the key changes needed to the common files needed to support AIX. Subsequent
patches will cover:
- changes to update the ppc directories so they are current with the changes
in the rest of the project.
- remaining AIX changes not resolved by 4.8 compiler
- individual optimizations for PPC
This is based off of the GitHub repository
https://github.com/andrewlow/v8ppcR=danno@chromium.org, svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/866843003
Cr-Commit-Position: refs/heads/master@{#26343}
In DevTools we need one more flag for script origin - is debugger script. We already have "is shared origin" flag. The new flag added by analogy with the old but new has accessor in script object.
R=yurys@chromium.org
Review URL: https://codereview.chromium.org/879553002
Cr-Commit-Position: refs/heads/master@{#26324}
This method circumvented JS semantics, and should not be used.
BUG=
Review URL: https://codereview.chromium.org/854493004
Cr-Commit-Position: refs/heads/master@{#26157}
Support for it is slow and difficult to implement, and it's not used in
Blink. An embedder that uses this feature will have to check the
argument types itself.
BUG=none
R=dcarney@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/848173002
Cr-Commit-Position: refs/heads/master@{#26058}
This API is used by Blink to inform V8 about HTML frames being disposed.
Using the optional parameter, Blink can tell V8 whether the disposed
frame was a main frame. In that case, we might want to reset GC
parameters
BUG=none
R=hpayer@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/823583003
Cr-Commit-Position: refs/heads/master@{#25926}
There might be a number of clients that would like to
setup an interrupt request on the Isolate.
The patch also deprecates ClearInterrupt API. As long as
the interrupt handler is called outside of locks there's no way
to guarantee that the handler will not be called after
ClearInterrupt was invoked as it might have already started execution.
Review URL: https://codereview.chromium.org/796623003
Cr-Commit-Position: refs/heads/master@{#25910}
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}
Also, remove V8_CC_CLANG since it's not read anywhere (and ideally shouldn't
be).
Clang tries to be compatible with gcc in clang mode, and with msvc in clang-cl
mode. It wants to go down the same code paths that these compilers want to go
down in most cases.
For example, V8PRIxPTR was set incorrectly on Windows 64-bit before this change
since macros.h assumed that checking for V8_CC_MSVC is enough to find LLP64
systems, but V8_CC_MSVC wasn't set for clang. Most other existing checks for
V8_CC_MSVC should be taken for clang-cl too (and for the remaining ones,
clang-cl is happy with either code path).
Likewise, V8_IMMEDIATE_CRASH is currently set to a suboptimal value with clang
since __builtin_trap() is only used if V8_CC_GNU is set.
Including clang in the gcc and cl macros is also what chromium does.
BUG=chromium:82385
LOG=y
Review URL: https://codereview.chromium.org/757553004
Cr-Commit-Position: refs/heads/master@{#25592}
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
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
