Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.
This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.
This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.
LOG=N
BUG=v8:4132
Review URL: https://codereview.chromium.org/1183733006
Cr-Commit-Position: refs/heads/master@{#29151}
Implements the strong mode proposal's restrictions on property access.
To be fully explored in a followup: proxies, interceptors, access checks, load from super
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1168093002
Cr-Commit-Position: refs/heads/master@{#29109}
On MIPS32 we can't read a 8 bytes long data from a not 8 bytes aligned memory address.
BUG=
TEST=mjsunit/debug-backtrace
Review URL: https://codereview.chromium.org/1193433002
Cr-Commit-Position: refs/heads/master@{#29100}
This is the first step towards unifying external and on-heap typed arrays.
The end-state will be that this base pointer either points to the on-heap values
or to the externally allocated array buffer.
BUG=v8:3996
R=hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1176263004
Cr-Commit-Position: refs/heads/master@{#29039}
Reasons:
- It is not used.
- It complicates code in GC.
BUG=chromium:499713
LOG=NO
Review URL: https://codereview.chromium.org/1184723002
Cr-Commit-Position: refs/heads/master@{#29027}
Otherwise using Object.defineProperty with window.localStorage will not actually store the value into the database but on the object itself.
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1180073002
Cr-Commit-Position: refs/heads/master@{#29002}
Reason for revert:
Blocks revert of https://codereview.chromium.org/1175973002
Original issue's description:
> Replace SetObjectProperty / DefineObjectProperty with less powerful alternatives where relevant.
>
> @yangguo: please look at the debugger part of the CL.
> @ishell: please look at the rest.
>
> Additionally:
> - Ensure the LookupIterator for named properties does not accidentally get indexes in.
> - Fix the return value for typed array assignments to be the incoming value.
>
> BUG=v8:4137
> LOG=n
>
> Committed: https://crrev.com/15aa811f8fe2708a757c3b53ca89db736aa8b222
> Cr-Commit-Position: refs/heads/master@{#28954}
TBR=yangguo@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4137
Review URL: https://codereview.chromium.org/1181733002
Cr-Commit-Position: refs/heads/master@{#28957}
@yangguo: please look at the debugger part of the CL.
@ishell: please look at the rest.
Additionally:
- Ensure the LookupIterator for named properties does not accidentally get indexes in.
- Fix the return value for typed array assignments to be the incoming value.
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1178503004
Cr-Commit-Position: refs/heads/master@{#28954}
We used to only store the uses_super_property in the preparse data
logger. Let the logger use NeedsHomeObject instead.
BUG=v8:3768
LOG=N
R=wingo, adamk
Review URL: https://codereview.chromium.org/1164073003
Cr-Commit-Position: refs/heads/master@{#28806}
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 also fixes issues with
- kMaxUint32 being a valid length but not index cornercases
- exotic integer objects masking "exotic indexes" even though its in the prototype chain
- concating of holey sloppy arguments
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1159433003
Cr-Commit-Position: refs/heads/master@{#28754}
Dictionary customization should be implemented in respective shape class.
Review URL: https://codereview.chromium.org/1160813009
Cr-Commit-Position: refs/heads/master@{#28738}
This updates Dictionary classes hierarchy and introduces GlobalDictionary class but it is not used yet.
Review URL: https://codereview.chromium.org/1163673003
Cr-Commit-Position: refs/heads/master@{#28732}
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code. The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++. Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.
Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
In a similar vein we could give the magic zero hash code to the hash code
symbol. Then when we look up the hash code we would sometimes see the table
with all the hidden properties. This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS. I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1149863005
Cr-Commit-Position: refs/heads/master@{#28622}
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 just delegates to SharedFunctionInfo::optimization_disabled and
was primarily used for assertions. Removing it due to misleading name
because already optimized functions reported being "non-optimizable".
This relands commit 181d7b8597.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1146423002
Cr-Commit-Position: refs/heads/master@{#28577}
Reason for revert:
Causes assertions to fire when serializing optimized code.
Original issue's description:
> Remove obsolete JSFunction::IsOptimizable predicate.
>
> This just delegates to SharedFunctionInfo::optimization_disabled and
> was primarily used for assertions. Removing it due to misleading name
> because already optimized functions reported being "non-optimizable".
>
> R=titzer@chromium.org
>
> Committed: https://crrev.com/181d7b85977eb752b19e1de902093783e31330ef
> Cr-Commit-Position: refs/heads/master@{#28551}
TBR=titzer@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1148973005
Cr-Commit-Position: refs/heads/master@{#28554}
This just delegates to SharedFunctionInfo::optimization_disabled and
was primarily used for assertions. Removing it due to misleading name
because already optimized functions reported being "non-optimizable".
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1150683002
Cr-Commit-Position: refs/heads/master@{#28551}
This allows enabling TurboFan on a certain subset of language features
in the AstNumberingVisitor. The heuristics of when to optimize remain
unchanged, only the choice of which optimizing compiler to use changes.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1155503002
Cr-Commit-Position: refs/heads/master@{#28544}
This flag mostly duplicates SharedFunctionInfo::optimization_disabled
and is only queried in places where the original is available. Remove
the brittle and error-prone duplication.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1148043002
Cr-Commit-Position: refs/heads/master@{#28520}
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}
In follow-up CLs the scavenger and the MC collector should also respect the unalignment of heap numbers.
BUG=
Review URL: https://codereview.chromium.org/1141523002
Cr-Commit-Position: refs/heads/master@{#28360}
This avoids DCHECK failures when passing 0 as the at_least_space_for
argument to HashTableBase::New (allowing converting code from non-serialized
to serialized without changing callsites).
Review URL: https://codereview.chromium.org/1134573002
Cr-Commit-Position: refs/heads/master@{#28321}
Allows for getting rid of the special casing for float64 and is probably
faster.
BUG=v8:3996
R=verwaest@chromium.org,dslomov@chromium.org,plind44@gmail.com
LOG=n
Review URL: https://codereview.chromium.org/1128433006
Cr-Commit-Position: refs/heads/master@{#28281}
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}
Original issue's description:
> Remove the weak list of array buffers
>
> Instead, collect live array buffers during marking and free pointers we
> no longer found.
>
> BUG=v8:3996
> R=hpayer@chromium.org
> LOG=n
BUG=v8:3996
TBR=hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1115853004
Cr-Commit-Position: refs/heads/master@{#28156}
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}
Reason for revert:
Breaks gbemu
Original issue's description:
> Reland "LayoutDescriptor should inherit from JSTypedArray"
>
> Original issue's description:
> > LayoutDescriptor should inherit from JSTypedArray
> >
> > It can't just inherit from a FixedTypedArray-like type, as we soon
> > assume that a FixedTypedArray-like type is always held by an
> > ArrayBufferView-like type
> >
> > BUG=v8:3996
> > R=ishell@chromium.org,verwaest@chromium.org
> > LOG=n
>
> BUG=v8:3996
> R=ishell@chromium.org,verwaest@chromium.org
> LOG=n
TBR=ishell@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996
Review URL: https://codereview.chromium.org/1080403004
Cr-Commit-Position: refs/heads/master@{#27975}
Original issue's description:
> LayoutDescriptor should inherit from JSTypedArray
>
> It can't just inherit from a FixedTypedArray-like type, as we soon
> assume that a FixedTypedArray-like type is always held by an
> ArrayBufferView-like type
>
> BUG=v8:3996
> R=ishell@chromium.org,verwaest@chromium.org
> LOG=n
BUG=v8:3996
R=ishell@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1094333002
Cr-Commit-Position: refs/heads/master@{#27973}
Reason for revert:
breaks mjsunit on debug bots
Original issue's description:
> LayoutDescriptor should inherit from JSTypedArray
>
> It can't just inherit from a FixedTypedArray-like type, as we soon
> assume that a FixedTypedArray-like type is always held by an
> ArrayBufferView-like type
>
> BUG=v8:3996
> R=ishell@chromium.org,verwaest@chromium.org
> LOG=n
TBR=ishell@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3996
Review URL: https://codereview.chromium.org/1073053006
Cr-Commit-Position: refs/heads/master@{#27968}
It can't just inherit from a FixedTypedArray-like type, as we soon
assume that a FixedTypedArray-like type is always held by an
ArrayBufferView-like type
BUG=v8:3996
R=ishell@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1084793004
Cr-Commit-Position: refs/heads/master@{#27964}
Also extract non-templated parts of HashTable class into HashTableBase.
Review URL: https://codereview.chromium.org/1095273002
Cr-Commit-Position: refs/heads/master@{#27959}
Calling new Array(JSObject::kInitialMaxFastElementArray) in optimized code
makes a stub call that bails out due to the length. Currently, the bailout
code a) doesn't have the allocation site, and b) wouldn't use it if it did
because the length is perceived to be too high.
This CL passes the allocation site to the stub call (rather than undefined),
and alters the bailout code to utilize the feedback.
BUG=
Review URL: https://codereview.chromium.org/1086873003
Cr-Commit-Position: refs/heads/master@{#27857}
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}
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}
The aforementioned predicate reported a JSFunction that was marked for
optimization as already compiled. This in turn also prevented us from
being aggressive about FLAG_always_opt treatment.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1019293003
Cr-Commit-Position: refs/heads/master@{#27481}
This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.
Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).
On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).
R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry
Review URL: https://codereview.chromium.org/1010883002
Cr-Commit-Position: refs/heads/master@{#27440}
Original issue: https://codereview.chromium.org/980573002/
Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.
Review URL: https://codereview.chromium.org/988703002
Cr-Commit-Position: refs/heads/master@{#27044}
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}
Reason for revert:
x64 test failures
Original issue's description:
> Simplify and compact transitions storage
>
> Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
> To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.
>
> Committed: https://crrev.com/45fbef7f2252fce10634931cb103ccc1fc95ae6a
> Cr-Commit-Position: refs/heads/master@{#27029}
TBR=verwaest@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/982143002
Cr-Commit-Position: refs/heads/master@{#27030}
Simple transitions are now stored in a map's "transitions" field (as a WeakCell wrapping the target map); full TransitionArrays are used when that's not sufficient.
To encapsulate these storage format implementation details, functions for manipulating and querying transitions have been refactored to be static functions on the TransitionArray class, and take maps as inputs.
Review URL: https://codereview.chromium.org/980573002
Cr-Commit-Position: refs/heads/master@{#27029}
This reverts commit b57be748b1 and
disables the test/mjsunit/debug-clearbreakpointgroup.js because
BreakLocationIterator::ClearBreakPoint is already broken for unrelated reasons (see v8:3924).
BUG=v8:3877
LOG=N
TEST=cctest/test-heap/Regress3877
Review URL: https://codereview.chromium.org/957373002
Cr-Commit-Position: refs/heads/master@{#26893}
Reason for revert:
Breaks test/mjsunit/debug-clearbreakpointgroup.js on arm64.debug.
Original issue's description:
> Fix memory leak caused by field type in descriptor array.
>
> When a field type is a map, it is wrapped in a weak cell upon storing to the descriptor array.
>
> Map::GetFieldType(i) does the unwrapping.
>
> BUG=v8:3877
> LOG=N
> TEST=cctest/test-heap/Regress3877
>
> Committed: https://crrev.com/77d3ae0e119893ac8d34ea6ca090cddd5bbf987e
> Cr-Commit-Position: refs/heads/master@{#26879}
TBR=verwaest@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3877
Review URL: https://codereview.chromium.org/960103003
Cr-Commit-Position: refs/heads/master@{#26883}
When a field type is a map, it is wrapped in a weak cell upon storing to the descriptor array.
Map::GetFieldType(i) does the unwrapping.
BUG=v8:3877
LOG=N
TEST=cctest/test-heap/Regress3877
Review URL: https://codereview.chromium.org/955063002
Cr-Commit-Position: refs/heads/master@{#26879}
Additionally handlify the "transition" field so that GC can stop caring about it.
BUG=
Review URL: https://codereview.chromium.org/935033003
Cr-Commit-Position: refs/heads/master@{#26718}
Previous approach for property reconfiguration was to create a free-floating map with generalized representations of all fields. This patch does it right.
When property is reconfigured either by changing its kind (kData <-> kAccessor) or its attributes it implies creation of a new branch in transition tree. If such a branch already existed before reconfiguration then it should be merged with the old (or source) branch of the transition tree. Merging procedure includes all the heavy machinery such as property location changes (kDescriptor -> kField), field representation/field type generalization, map deprecation, etc.
Review URL: https://codereview.chromium.org/888623002
Cr-Commit-Position: refs/heads/master@{#26667}
Removed useless (and in the future incorrect) DCHECKs on the way.
Review URL: https://codereview.chromium.org/921443004
Cr-Commit-Position: refs/heads/master@{#26655}
With the new ES6 semantics super construct calls are only valid in
a constructor in a derived class. This is something that is
statically known and we report early SyntaxError in case it occurs.
We therefore do not need to track this any more.
BUG=v8:3330
LOG=N
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/924123002
Cr-Commit-Position: refs/heads/master@{#26644}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
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}
This solves an issue with the custom startup snapshot, in cases where
deserializing the isolate requires more than one page per space.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/876613002
Cr-Commit-Position: refs/heads/master@{#26285}
Use std::numeric_limits<double>::quiet_NaN() and
std::numeric_limits<float>::quiet_NaN() instead.
Review URL: https://codereview.chromium.org/864803002
Cr-Commit-Position: refs/heads/master@{#26195}
Math functions:
Some Math functions require typed arrays for their implementation. The embedded
script may call those Math functions. The serializer needs to deal with this.
Added assertion to make sure no other typed array is created when snapshotting.
Number-string cache:
We assume that the initial snapshot does not expand the number-string cache.
This is no longer true for custom heap snapshots.
Bound functions:
Bound functions store the bound arguments in a COW fixed array, including the
bindee function. COW arrays are serialized into the startup snapshot and
referenced in the partial snapshot via partial snapshot cache. However, the
bindee function is context-dependent and must not be part of the startup
snapshot. There is no need for bound functions to use a COW array though.
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/851073002
Cr-Commit-Position: refs/heads/master@{#26072}
This is not needed anymore since all ICs use weak cells to embed maps.
BUG=v8:3629
LOG=N
Review URL: https://codereview.chromium.org/817223003
Cr-Commit-Position: refs/heads/master@{#25928}
There are no users of this infrastructure yet, so it's behind an off-by-default flag.
Review URL: https://codereview.chromium.org/768633002
Cr-Commit-Position: refs/heads/master@{#25829}
This functionality is now used by both object visitor and store buffer.
TEST=cctest/test-unboxed-doubles
Review URL: https://codereview.chromium.org/726713003
Cr-Commit-Position: refs/heads/master@{#25816}
They both now run fast (due to utilizing transitions instead of always
creating new maps) and sealed or non-extensible objects can stay in
fast mode after transitioning.
This almost entirely reuses the code for transitioning objects
frozen by Object.freeze(), with the added benefit of freeing
up a bit on the map (we no longer keep track of frozen-ness,
as that bit wasn't used for anything interesting).
BUG=v8:3662,chromium:115960
LOG=y
Review URL: https://codereview.chromium.org/776143005
Cr-Commit-Position: refs/heads/master@{#25759}
When compiling with the macro DCHECK_ALWAYS_ON defined, DCHECKs and
supporting code gets compiled and enabled.
This increases test coverage for chromium release buildbots
BUG=v8:3731
R=jkummerow@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/760213005
Cr-Commit-Position: refs/heads/master@{#25701}
This combines Map::DoneInobjectSlackTracking and Map::ConstructionCount into one more generic 4-bit counter.
Counter values from 15 down to 8 are used for in-object slack tracking, values from 7 down to 0 are free to be used for a new counter when in-object slack tracking is inactive.
Review URL: https://codereview.chromium.org/767253002
Cr-Commit-Position: refs/heads/master@{#25689}
This relands macroassembler instructions and weak cell caching and
does not include parts that caused "Linux ASan LSan" test failures.
BUG=v8:3663
LOG=N
Review URL: https://codereview.chromium.org/764003003
Cr-Commit-Position: refs/heads/master@{#25615}
Previously, a separate string to be hashed (in order to help determine the need to
use a cached Template Call Site) was built up by joining UTF8 spans within a template.
Now, the hash key is generated from the original spans, removing the need to allocate a new
buffer and copy bytes into it.
BUG=
Review URL: https://codereview.chromium.org/765473006
Cr-Commit-Position: refs/heads/master@{#25549}
Revert "Fix for an assertion failure in Map::FindTransitionToField(...). Appeared after r25136."
This revert is made in order to revert r25099 which potentially causes renderer hangs.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/722873004
Cr-Commit-Position: refs/heads/master@{#25332}
