Replace the ADD, SUB, etc. builtins with proper runtime implementations,
and expose them as runtime calls that can be used by the code stubs and
the interpreter (for now).
Also remove all the support runtime functions for ADD, SUB and friends,
namely %NumberAdd, %NumberSub, and so on.
R=mstarzinger@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
Review URL: https://codereview.chromium.org/1333843002
Cr-Commit-Position: refs/heads/master@{#30680}
When looking up a special accessor for known TypedArray fields
("length", "byteLength", "byteOffset"), consider the entire prototype
chain, not only the direct prototype.
This allows subclasses of TypedArrays to benefit from fast specialized
accesses.
Review URL: https://codereview.chromium.org/1313493005
Cr-Commit-Position: refs/heads/master@{#30678}
This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1322883002
Cr-Commit-Position: refs/heads/master@{#30500}
This is the first step towards a spec compliant ToPrimitive
implementation (and therefore spec compliant ToNumber, ToString,
ToName, and friends). It adds support for the @@toPrimitive
symbol that was introduced with ES2015, and also adds the new
Symbol.prototype[@@toPrimitive] and Date.prototype[@@toPrimitive]
initial properties.
There are now runtime functions for %ToPrimitive, %ToNumber and
%ToString, which do the right thing and should be used as fallbacks
instead of the hairy runtime.js implementations. I will do the
same for the other conversion operations mentioned by the spec in
follow up CLs. Once everything is in place we can look into
optimizing things further, so that we don't always call into the
runtime.
Also fixed Date.prototype.toJSON to be spec compliant.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=y
Review URL: https://codereview.chromium.org/1306303003
Cr-Commit-Position: refs/heads/master@{#30434}
Up until now we can only inline based on JSFunction, because of the way
the deoptimization works. With this change we will be able to inline
based on the SharedFunctionInfo and materialize the JSFunction from a
literal or a stack slot when necessary.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1169103004
Cr-Commit-Position: refs/heads/master@{#28906}
This unifies methods Deoptimizer::DoTranslateCommand, Deotpimizer::DoTranslateObject and the arguments object materializer.
To unify these, we have to separate reading of the input frame from writing to the output frame because the argument materializer does not write to output frames.
Instead, we now deoptimize in following stages:
1. Read out the input frame/registers, decode them using the translations from the deoptimizer and store them in the deoptimizer (Deoptimizer::translated_state_). This is done in TranslatedState::Init.
2. Write out into the output frame buffer all the values that do not require allocation. We also remember references to the values that require materialization. As before, this is done in Deoptimizer::DoCompute*Frame method, but instead calling to DoTranslateCommand, we use the translated frame to obtain the values and write them to the output frames.
3. The platform specific code then sets up the output frames and calls into the deoptimization notification. This has not been changed at all.
4. Once the stack is setup, we handlify all the references in the saved translated values (TranslatedState::Prepare).
5. Finally, we materialize all the values we remembered in step (1) and write them to their frames on the stack (using the TranslatedValue::GetValue method).
BUG=
Review URL: https://codereview.chromium.org/1136223004
Cr-Commit-Position: refs/heads/master@{#28826}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
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}
Reason for revert:
I'm reverting this while working on the regression fix
Original issue's description:
> Remove the weak list of views from array buffers
>
> Instead, views have to check their array buffer for whether
> it's neutered or not.
>
> BUG=v8:3996
> R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
> LOG=n
>
> Committed: https://crrev.com/5ae083a05a6743d6cb91585f449539f7846a5d8c
> Cr-Commit-Position: refs/heads/master@{#27995}
TBR=dslomov@chromium.org,hpayer@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996
Review URL: https://codereview.chromium.org/1061753008
Cr-Commit-Position: refs/heads/master@{#28014}
Instead, views have to check their array buffer for whether
it's neutered or not.
BUG=v8:3996
R=hpayer@chromium.org,dslomov@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1094863002
Cr-Commit-Position: refs/heads/master@{#27995}
Escaping used to happen lazily, implemented in an accessor property.
However, native implementation of RegExp methods use .source as well.
This leads to performance regressions. Now we do it eagerly instead.
R=jkummerow@chromium.org
BUG=chromium:436447
LOG=N
Review URL: https://codereview.chromium.org/1070093002
Cr-Commit-Position: refs/heads/master@{#27705}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
Function name property is now standardized in ES6. It was a Mozilla proprietary
extension before. With ES6, the property was made configurable, so that it can
be used instead of another proprietary property, displayName.
This is a revert of revert c791d84112.
Last time this broke a Chrome browser test which has since been updated:
5f75a3be4c
BUG=v8:3333
LOG=N
R=mstarzinger@chromium.org,verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/977003004
Cr-Commit-Position: refs/heads/master@{#26996}
This is partially based on r21609 but that CL was incomplete.
Function name is still non writable so one has to use defineProperty
to change the actual value.
BUG=v8:3333
LOG=N
R=adamk, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/960343002
Cr-Commit-Position: refs/heads/master@{#26924}
We no longer expect NewError to return an empty handle to signal termination
exception, since TryCall simply requests a new terminate exception interrupt.
BUG=chromium:403509
LOG=N
Review URL: https://codereview.chromium.org/952483002
Cr-Commit-Position: refs/heads/master@{#26811}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
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}
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
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
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
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
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
