By not having to patch the return sequence (we patch the debug
break slot right before it), we don't overwrite it and therefore
don't have to keep the original copy of the code around.
R=ulan@chromium.org
BUG=v8:4269
LOG=N
Review URL: https://codereview.chromium.org/1234833003
Cr-Commit-Position: refs/heads/master@{#29672}
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}
