This reverts commit d3104923b2.
Reason for revert: Breaks win debug, causes lots of timeouts.
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/20387
Original change's description:
> Implement and use VectorSegment to avoid repeated allocation of ZoneVector properties.
>
> The parser holds a single vector whose backing storage is reused in calls
> to ParseJsonObject, so that once we reach the peak number of unstored
> properties no more allocations are required.
>
> This improves performance of parsing inputs like those in Speedometer VanillaJS
> by about 2% in my local measurement, and would presumably do better on more
> pathological inputs.
>
> This should also have the side effect of reducing peak memory usage at this time
> slightly, since we do fewer zone allocations which cannot be freed until the
> parse finishes.
>
> Bug: chromium:771227
> Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
> Reviewed-on: https://chromium-review.googlesource.com/789511
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Jeremy Roman <jbroman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49693}
TBR=jbroman@chromium.org,marja@chromium.org,cbruni@chromium.org
Change-Id: I5b198aeffed6f1543f6110709dc74b311d4ba144
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:771227
Reviewed-on: https://chromium-review.googlesource.com/796151
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49705}
In TurboFan we can easily recognize calls to String.prototype.slice
where the start parameter is -1 and the end parameter is either
undefined or not present. These calls either return an empty string if
the input string is empty, or the last character of the input string
as a single character string. So we can just make use of the existing
StringCharAt operator.
This reduces the overhead of the String.prototype.slice calls from
optimized code in the chai test of the web-tooling-benchmark
significantly. We observe a 2-3% improvement on the test.
Bug: v8:6936, v8:7137
Change-Id: Iebe02667446880f5760e3e8c80f8b7cc712df663
Reviewed-on: https://chromium-review.googlesource.com/795726
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49704}
This reverts commit 99cb4d35a3.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/16445
Original change's description:
> [cleanup] Harden the SubString CSA/Runtime implementations.
>
> Remove the self-healing for invalid parameters in the
> CodeStubAssembler::SubString helper and the %SubString runtime function,
> which is used as a fallback for the CodeStubAssembler implementation.
> All call sites must do appropriate parameter validation anyways now that
> the self-hosted JavaScript builtins using these helpers are gone, and we
> have proper contracts with the uses.
>
> Also remove the context parameter from the CodeStubAssembler::SubString
> method, which is unnecessary, since this can no longer throw an
> exception.
>
> Bug: v8:5269, v8:6936, v8:7109, v8:7137
> Change-Id: I19d93bad5f41faa0561c4561a48f78fcba99a549
> Reviewed-on: https://chromium-review.googlesource.com/795720
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49702}
TBR=jgruber@chromium.org,bmeurer@chromium.org
Change-Id: I2900b5f087e78f1d321724f03bd063a5ff094183
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5269, v8:6936, v8:7109, v8:7137
Reviewed-on: https://chromium-review.googlesource.com/796150
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49703}
Remove the self-healing for invalid parameters in the
CodeStubAssembler::SubString helper and the %SubString runtime function,
which is used as a fallback for the CodeStubAssembler implementation.
All call sites must do appropriate parameter validation anyways now that
the self-hosted JavaScript builtins using these helpers are gone, and we
have proper contracts with the uses.
Also remove the context parameter from the CodeStubAssembler::SubString
method, which is unnecessary, since this can no longer throw an
exception.
Bug: v8:5269, v8:6936, v8:7109, v8:7137
Change-Id: I19d93bad5f41faa0561c4561a48f78fcba99a549
Reviewed-on: https://chromium-review.googlesource.com/795720
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49702}
This updates various typing and verification rules to take bigints into
account.
R=jarin@chromium.org
Bug: v8:6791
Change-Id: I38fc4c6551bba878623373c69013da8ce2b50c7d
Reviewed-on: https://chromium-review.googlesource.com/788910
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49701}
This is a reland of acfef3ec93
Original change's description:
> [log] Properly log all maps creating during bootstrapping
>
> Logger::LogMaps will print all maps currently present on the heap.
>
> Note that currently this does not properly log the detailed transitions
> for these maps.
>
> Change-Id: Ia3218d371549d7634fe3eda9e8e59b0b0bd8bebb
> Reviewed-on: https://chromium-review.googlesource.com/753885
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49444}
Change-Id: I57830f1e22c09981761bb92b9d28c96fbcc1ee80
Reviewed-on: https://chromium-review.googlesource.com/775958
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49699}
This will break the bot. This is for getting a stack trace and then
revert.
TBR=mtrofin@chromium.org
Bug: v8:7138
Change-Id: I244492ca81f817d64ef7c12e291a6ed9b97e68de
Reviewed-on: https://chromium-review.googlesource.com/795718
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49698}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
The two helper functions CanBePrimitive and NeedsConvertReceiver did
essentially the same, just in a slightly different way, and both weren't
really robust wrt. to the list of JSConstruct* and JSCreate* operators
that they were handling. There's now a single helper in the
NodeProperties and a couple of extra macro lists to keep this list up
to date more easily.
Drive-by-fix: Also moved the CanBeNullOrUndefined helper to the
NodeProperties class.
Bug: v8:5267, v8:7109
Change-Id: Ibbf387040e3f424ee224c53fac15c2b3207b1926
Reviewed-on: https://chromium-review.googlesource.com/793734
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49695}
The parser holds a single vector whose backing storage is reused in calls
to ParseJsonObject, so that once we reach the peak number of unstored
properties no more allocations are required.
This improves performance of parsing inputs like those in Speedometer VanillaJS
by about 2% in my local measurement, and would presumably do better on more
pathological inputs.
This should also have the side effect of reducing peak memory usage at this time
slightly, since we do fewer zone allocations which cannot be freed until the
parse finishes.
Bug: chromium:771227
Change-Id: I8aa1514b37a74f82539f95f94292c8fa1582d66a
Reviewed-on: https://chromium-review.googlesource.com/789511
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49693}
While investigating loop peeling, I found that relatively simple code
like "if (x) { throw new Error('oh hai'); }" in a loop would fail to
peel. The reason is that the call (new Error(...)) was recorded by
loop analysis as being inside the loop but the only usage was in the throw,
which we currently model as being outside of the loop.
We have a regime that inserts LoopExit nodes to mark control exits from
the loops, and LoopExitValues that are meant to mark exiting values.
This wasn't done because of a bug in the bytecode graph builder
VisitThrow() method -- it used the *out* liveness to construct the
appropriate loop exit nodes, and it's more appropriate to use the *in*
liveness.
This addressed the concern. It doesn't fix bug 7099, but is a step on the
way.
Bug: v8:7099
Change-Id: Iaeea794843166063a55c6917e7b0ad4341581261
Reviewed-on: https://chromium-review.googlesource.com/793834
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49690}
This is the first step towards wasm code sharing. This CL moves wasm
code generation outside the JavaScript GC heap using the previously -
introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
flag).
See design document: go/wasm-on-native-heap-stage-1
This CL doesn't change other wasm architectural invariants. We still
have per-Isolate wasm code generation, and per-wasm module instance
code specialization.
Bug:v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
Reviewed-on: https://chromium-review.googlesource.com/674086
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49689}
It was shipped in Chrome 62.
Bug: v8:5546, v8:4829
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3ac318639f1f7483d4d4f4fe5606387a856be98a
Reviewed-on: https://chromium-review.googlesource.com/777940
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49687}
These tests are failing with OOM.
Bug: v8:6924
Change-Id: I988814350c6199ca5c1976e3f09d3b96e42ec0ff
Reviewed-on: https://chromium-review.googlesource.com/793044
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49686}
This reverts commit adf0fc8c59.
Original change's description:
> [heap] Tune incremental marking step size.
>
> The main thread now can reduce marking step size if concurrent marking
> tasks are making progress and the bailout worklist is empty.
>
> Bug: chromium:694255
Change-Id: Ib2f04be258e14887059d88da301ddf17f6b453b4
Reviewed-on: https://chromium-review.googlesource.com/794135
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49685}
And also ensure that it doesn't allocate when that's avoidable.
Bug: v8:6791
Change-Id: Ied2d2c9c5718aed9839f17739d743353cbadee88
Reviewed-on: https://chromium-review.googlesource.com/786170
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49683}
There are several places where we extract function information
(instance and function index) from the deoptimization data. Add a
central method to do this.
Drive-by: Move {AttachWasmFunctionInfo} from wasm-compiler.h to
wasm-objects.h.
R=titzer@chromium.org
Change-Id: I768d2c9aa8049f75a6be02242b1fe524ff42e3e4
Reviewed-on: https://chromium-review.googlesource.com/793046
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49682}
- Use madvise when setting no permissions on memory.
- Move platform specific mmap flag calculations to a helper fn.
Bug: chromium:756050,chromium:788341
Change-Id: I7d420a0abee9656a57fb0317301322da2fd7d7b5
Reviewed-on: https://chromium-review.googlesource.com/790932
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49681}
This way it can already be used during deserialization.
Bug: v8:7133
Change-Id: I6d6ddb6c6e5326384d014d653b163f3d917089e9
Reviewed-on: https://chromium-review.googlesource.com/793393
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49679}
Use memmove if source and target are either Uint8Array or Uint8ClampedArray.
Bug: v8:7123,chromium:759236
Change-Id: If82bf10165cfc67274f36bb772ce9676a768dcc8
Reviewed-on: https://chromium-review.googlesource.com/790756
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49678}
AggregatableHistogramTimer will always add a sample when it is destroyed,
even if there were no AggregatedHistogramTimerScope called within it. This
makes the V8.CompileLazyMicroSeconds histogram not particularly useful since
it is 90% filled with zero entries where v8 execute didn't require any
lazy function compilation
Change-Id: Ia75c8596237b22528cbba3e8ae2b67e28ea54097
Reviewed-on: https://chromium-review.googlesource.com/793452
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49674}
These fields relied on the assumption that 64-bit big-endian
architectures had sizeof(int) == 4. Any architecture violating this
assumption would result in an OOB access.
Bug:
Change-Id: I682ecb6a2da2cf84e8b24f1c1e608d7fc23f5bdc
Reviewed-on: https://chromium-review.googlesource.com/793431
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49673}
The main thread now can reduce marking step size if concurrent marking
tasks are making progress and the bailout worklist is empty.
Bug: chromium:694255
Change-Id: I2f58530f184c03667ab3a170a1f6309929645c7c
Reviewed-on: https://chromium-review.googlesource.com/735859
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49671}
Many methods which currently receive a {ValueType} really just need to
know the register class. Thus introduce a {RegClass} enum with values
{kGpReg} and {kFpReg}, and change some methods to use it. For most
methods, only the {kGpReg} case is implemented for now. Support for
{kFpReg} will be added later.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I1db793c59270862c4e1b877e6e4bd81020a650f8
Reviewed-on: https://chromium-review.googlesource.com/793159
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49670}
This CL adds the --trace-wasm-lazy-compilation flag, to track which
function is being compiled, and how many locations in the caller and in
function tables are actually being patched.
It seems that we currently don't patch the caller correctly when
calling through wasm-to-wasm stubs, and this tracing helps to find the
issue.
Drive-by: Fix order and location of macro undefs.
R=titzer@chromium.org
Bug: chromium:788441
Change-Id: I6091c0d490a729f8e3cb759cd661cf52129d2211
Reviewed-on: https://chromium-review.googlesource.com/793157
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49669}
On 64-bit architectures, an IntPtr-sized write of Name::kEmptyHashField
will properly initialize the relevant Int32-sized payload of
Name::kHashFieldOffset, as well as zero out the unused portion of the
slot.
Bug: v8:7065
Change-Id: I93113c9744377e76cd0d264568c49b31a1e822a1
Reviewed-on: https://chromium-review.googlesource.com/788530
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49668}
We'd sometimes forget that the input was not originally a numeric.
Bug: v8:7135
Change-Id: I8bc690cc0c2dfac8a2a218ca56352b6a569825dc
Reviewed-on: https://chromium-review.googlesource.com/793039
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49667}
This is reland of 3e0bf580e8
Original change's description:
> This commit is a step toward enabling test-run-wasm-simd tests for MIPS.
> 36 of those were failing in V8 builtin simulator because some instructions
> were not implemented. Also there are minor fixes to some of the already
> implemented instructions.
>
> This commit has only 32-bit implementation. After review I will add
> 64-bit version.
>
> Bug:
> Change-Id: I25b0cac352db3efb56b922ace64ab2aaef82472d
> Reviewed-on: https://chromium-review.googlesource.com/744008
> Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
> Cr-Commit-Position: refs/heads/master@{#49439}
Bug:
Change-Id: I3a904caf675d314186c02c1c843d1e6a91a21a14
Reviewed-on: https://chromium-review.googlesource.com/776813
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#49666}
Properly handle known JSBoundFunction instances as targets to
JSConstruct by inlining the construction of the eventual target.
Also if the target is the result of a JSCreateBoundFunction call,
where we can also fold the construction and construct the bound
target function directly instead.
This addresses half of the TODO in the JSConstruct lowering in the
JSCallReducer where so far we didn't handle bound functions.
Bug: v8:5267, v8:7109
Change-Id: I022dc7d4fbbe2c9972472e78a6d64f51e3134c94
Reviewed-on: https://chromium-review.googlesource.com/792947
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49664}
This reverts commit 61367a25fa.
Reason for revert: http://shortn/_amqTfxgjk0
Original change's description:
> [platform][cleanup] Fix --enable-tracing
>
> The flag --enable-tracing can be used to measure how much time is spent
> in a scope. In d8 this flag did not work properly for the following
> reasons:
>
> * The tracing file is not written when the JavaScript code calls quit().
>
> * The tracing file is not written when the JavaScript code throws an
> uncaught exception, except if the --throws flag is passed to d8.
>
> The reason for these two issues is that both call Shell::Exit(), which
> end d8 immediately without calling any destructors. In addition I moved
> in a recent CL the destruction of the platform after the destruction of
> the file handle for the tracing file. Thereby the tracing file did not
> get filled with content even destructors were executed.
>
> With this CL I also call the destructors of the platform and of the file
> handle in the Shell::Exit() function. For this I make Shell::Exit()
> platform independent and let it call the platform dependent
> Shell::OSExit() at the end.
>
> R=rmcilroy@chromium.org
>
> Change-Id: I14425b6a5c25b757211bc8b9959a9cc8bfa0602c
> Reviewed-on: https://chromium-review.googlesource.com/789038
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49659}
TBR=rmcilroy@chromium.org,ahaas@chromium.org
Change-Id: I17c6f19c38cb337b00707f606f267b52b7f2c1e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/792991
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49663}
In a recent CL I introduced module-level CodeSpaceMemoryModificationScopes,
which means that the number of CodeSpaceMemoryModificationScopes which
are opened aside from TurboFan compilation is not linear in the number
of functions anymore. In that CL, however, I did not remove scopes which
became obsolete. This CL removes now these obsolete scopes, and
introduces some scopes where shared code was used from outside the
compilation logic.
R=mstarzinger@chromium.org, clemensh@chromium.org
Bug: chromium:787731
Change-Id: I37d514efa3a4b10adb7008986a9c91e4557ce618
Reviewed-on: https://chromium-review.googlesource.com/790490
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49662}
Change the existing uses of the harmony-class-fields flag to
harmony-public-fields so that we can stage this separately
from the upcoming harmony-private-fields to get some
clusterfuzz coverage.
Bug: v8:5367
Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a
Reviewed-on: https://chromium-review.googlesource.com/792940
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49661}
The flag --enable-tracing can be used to measure how much time is spent
in a scope. In d8 this flag did not work properly for the following
reasons:
* The tracing file is not written when the JavaScript code calls quit().
* The tracing file is not written when the JavaScript code throws an
uncaught exception, except if the --throws flag is passed to d8.
The reason for these two issues is that both call Shell::Exit(), which
end d8 immediately without calling any destructors. In addition I moved
in a recent CL the destruction of the platform after the destruction of
the file handle for the tracing file. Thereby the tracing file did not
get filled with content even destructors were executed.
With this CL I also call the destructors of the platform and of the file
handle in the Shell::Exit() function. For this I make Shell::Exit()
platform independent and let it call the platform dependent
Shell::OSExit() at the end.
R=rmcilroy@chromium.org
Change-Id: I14425b6a5c25b757211bc8b9959a9cc8bfa0602c
Reviewed-on: https://chromium-review.googlesource.com/789038
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49659}
... in the same style as the previous CLs for negation and bitwise-not.
R=jarin@chromium.org
Bug: v8:6791
Change-Id: I0aa96a72421e90c8c82a39dd4264fdcf00967504
Reviewed-on: https://chromium-review.googlesource.com/779141
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49658}
Modification of InstanceType enum caused JsonStringifier::Serialize_() function
to consume more stack space (because of a switch statement) in non-optimized
debug build which now causes stack overflow on certain depth of nested objects.
The modification affects neither optimized debug nor release builds.
Change-Id: Ia2925d9abbd1c32c5a4694e14c49b2d0bd119419
Reviewed-on: https://chromium-review.googlesource.com/789074
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49657}
