Note that there are currently no objects that require a pre-allocated
properties backing store, all such slots are in-object properties from
the begining. Hence {unused + pre_allocated - inobject == 0} holds.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1226203011
Cr-Commit-Position: refs/heads/master@{#29590}
This allows context-independent code generated by TurboFan to be cached
in the optimized code map and reused across native contexts. Note that
currently this cache is still flushed at GC time.
R=bmeurer@chromium.org,mvstanton@chromium.org
TEST=cctest/test-compiler/OptimizedCodeSharing
Review URL: https://codereview.chromium.org/1208013002
Cr-Commit-Position: refs/heads/master@{#29313}
Speculative revert in the hopes of fixing serializer crashes seen in canary.
This reverts commit c166945083, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967bb7).
BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1207583002
Cr-Commit-Position: refs/heads/master@{#29241}
This fixes a terrible interaction of code flushing and the clearing of
optimized code maps hanging off a SharedFunctionInfo. The following is
what happened:
1) Incremental marking cleared map in SharedFunctionInfo s, however it
was not enqueued as a flushing candidate because one JSFunction f1
still had optimized code.
2) Deoptimization of f1 made s eligible for code flushing.
3) Optimization of f2 added new entry to optimized code map of s.
4) The JSFunction f2 became unreachable and hence is never marked.
5) Incremental marking now visits f1, finds it eligible for flushing,
also s is eligible for flushing, both are enqueued.
6) Marking finishes, code flusher clears f1 and s, but the optimized
code map of s still contains an entry.
7) Boom!
R=ulan@chromium.org,hpayer@chromium.org
TEST=mjsunit/es6/generators-iteration
BUG=v8:3803
LOG=N
Review URL: https://codereview.chromium.org/1197713004
Cr-Commit-Position: refs/heads/master@{#29177}
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}
Allocation must respect requested reserve size, not requested commit area size.
Additionally fix check failures in debug mode for mips64.
After CL: https://codereview.chromium.org/1147503002/
memory for large code objects is allocated from code range,
memory for regular code objects is allocated normally.
TEST=cctest/test-spaces/MemoryChunk
BUG=
Review URL: https://codereview.chromium.org/1172333002
Cr-Commit-Position: refs/heads/master@{#28995}
Two changes:
- In ReportBootstrappingException, if all we have is a string, it seems
better to print that than nothing.
- In Factory::NewError, there's no use trying to call into the builtins if
compilation of the builtins is causing the exception (this currently
results in a cryptic segfault if we trigger, say, a ReferenceError when
executing builtins script during bootstrapping).
Review URL: https://codereview.chromium.org/1158013003
Cr-Commit-Position: refs/heads/master@{#28912}
Boolean "is_strong" parameters have begun to proliferate across areas where
strong mode semantics are different. This CL repurposes the existing
ObjectStrength enum as a replacement for them.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1144183004
Cr-Commit-Position: refs/heads/master@{#28839}
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}
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}
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}
* 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}
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}
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}
This fixes a race where
- mutator changes the fixed array length by trimming it,
- sweeper thread reads the length of the fixed array.
Also rename FROM_GC and FROM_MUTATOR to be more precise.
BUG=chromium:462908
LOG=NO
Review URL: https://codereview.chromium.org/1034163002
Cr-Commit-Position: refs/heads/master@{#27869}
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
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}
No compiler support for now (BTW: %_NewString, doesn't have that,
either), inline allocation will come later. Hopefully the last
intrisic to add for a StringAddStub POC...
Review URL: https://codereview.chromium.org/1041723002
Cr-Commit-Position: refs/heads/master@{#27508}
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 allows using %OptimizeFunctionOnNextCall and friends even when
Crankshaft is disabled. Note that this should only affect code paths
that are not relevant to performance. By now we have a single bailout
point in place within OptimizedCompileJob::CreateGraph that ensures
Crankshaft is only used when enabled and supported.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/999173007
Cr-Commit-Position: refs/heads/master@{#27367}
The cause was dynamic allocation of an accounting structure used to
create/initialize the type feedback vector, done at the end of the
numbering pass. The solution is to Zone-allocate the structure to
bring it's lifetime in line with the compilation unit.
BUG=
Review URL: https://codereview.chromium.org/1014793003
Cr-Commit-Position: refs/heads/master@{#27241}
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}
and "Just visit young array buffers during scavenge. Additionally keep the views in new space in a separate global list and move them to the corresponding array buffers when they get promoted."
This reverts commit 295ab27830
and commit bd61a85faf.
TBR=hpayer@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/929973002
Cr-Commit-Position: refs/heads/master@{#26653}
This reduces young generation garbage collections when many array buffers are allocated.
BUG=
Review URL: https://codereview.chromium.org/904633003
Cr-Commit-Position: refs/heads/master@{#26605}
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}
size_t is the correct data type for this purpose. Our APIs (in particular
ExternalSourceStream::GetMoreData) are already using it, and there were some
static_casts to convert between them.
This CL doesn't intend to fix all of V8, just the minimal sense-making part
around scanner character streams.
BUG=
Review URL: https://codereview.chromium.org/864273005
Cr-Commit-Position: refs/heads/master@{#26449}
This reverts commit f578d35ba8 because
(immutable) heap numbers are surprisingly mutable in V8. Someone else
might want to cleanup the mess, otherwise we'll just keep it this way.
TBR=jkummerow@chromium.org
BUG=chromium:454894
LOG=y
Review URL: https://codereview.chromium.org/898973003
Cr-Commit-Position: refs/heads/master@{#26447}
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}
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}
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}
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}
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 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}
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
All JSObjects in V8 either have a map()->constructor() field or are
JSFunctions. JSProxy::Fix, however, was not enforcing this, and
Object.observe's use of JSObject::GetCreationContext() exposed this.
Note that this is not Object.observe-specific: the API call
v8::Object::CreationContext() also would have revealed this bug.
This patch chooses Object as a reasonable constructor to put on the
newly-fixed object's map. Note that this has no effect on the "constructor"
property in JS. In doing so, I've also tightened up the code underlying
JSProxy::Fix to only support JSObject and JSFunction as possible output
types.
BUG=405844
LOG=N
R=rossberg@chromium.org, verwaest@chromium.org
Review URL: https://codereview.chromium.org/505303004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23466 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a step in the direction of disentangling all uses of SetOwnPropertyIgnoreAttributes so we can provide a more specific implementation for those usecases, and reduce the capabilities of those clients, avoiding subtle bugs.
InitializeProperty only supports adding properties to extensible objects that do not contain the property yet. JSGlobalProxies cannot have properties themselves, so are not supported either.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/352813002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22095 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of using an iterator result object and an entries array
(for Map) we introduce a new runtime function that uses an array
as an out param.
On the Map ForEach perf test this leads to a 2.5x performance
improvement. On the overall Map and Set tests this leads to a 18%
and 13% improvement respectively.
BUG=None
LOG=Y
R=danno@chromium.org
Review URL: https://codereview.chromium.org/355663002
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22027 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds support for ConstantPoolArrays which contain an extended section.
This will be used to enable larger constant pools than can be addressed by a
single ldr with immediate offset instruction (which has a limit of a 4KB range).
Extended constant pools will have a small section, which is addressable via a
single ldr instruction, and an extended section, which will require a multi-
instruction sequence to load from.
Currently, no code uses the extended ConstantPoolArray's - this change will
be made in a followup CL.
A number of changes are made to the ConstantPoolArray object in order to
support this:
- Small section layout is now entirely defined by the small layout bitmaps.
- The ConstantPoolArray no longer extends FixedArrayBase since the length
field is not useful for extended layouts.
- Enums are used to represent the type of an entry and the layout section.
- An iterator can be used to iterate through all elements of a given type.
- A number of tests were added for these features.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/304143002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21653 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
